TDD *

Хотел бы сказать пару слов о книге Professional Test Driven Development with C#. Выбрать книгу по популярным технологиям и техникам программирования не так сложно. На каждом форуме написано, что если хочешь познать .NET – не обойтись без Рихтера. Сложнее с менее популярными темами. Итак, TDD…

В этой статье я хочу поделиться опытом создания инфраструктуры для интеграционного тестирования веб приложения. Приложение построено на платформе .Net и состоит из ASP.NET MVC приложения и базы данных на MSSQL

Задача интеграционного тестирования формулировалась следующим образом: автоматизировать развёртывание приложения и выполнение тестов пользовательского интерфейса, чтобы можно было быстро убедиться в том, что устанавливаемая версия приложения успешно отрабатывает все необходимые тестовые сценарии.

Другими словами надо быстро проверить, что будет, когда мы установим новую версию заказчику и начнём с ней работать. Поскольку, результат выполнения этих тестов является показателем качества создаваемого приложения, мы всегда будем знать качество нашего приложения, а значит и ситуацию в которой мы находимся.

Поскольку интеграционное тестирование позволят имитировать действия пользователя можно сказать, что оно позволят проверять факт того, что такой-то пункт ТЗ успешно выполнен. Если создать тесты для каждого пункта ТЗ (то получим программу и методику испытаний — ПМИ :) и автоматизировать их, то количество успешно выполненных тестов будет означать реальную информацию о том, на сколько процентов исполнено ТЗ. Иначе оценка состояния системы будет выглядеть следующим образом:
— Ну как у нас сегодня система, если одним словом?
— Если одним словом, то… работает.
— А если в двух словах?
— А если в двух словах, то не работает.

Что должно проверяться при таком тестировании:
— Компиляция и сборка приложения
— Процедура установки или обновления приложения:
— Установка новой или обновление существующей базы данных
— Установка нового ASP.NET приложения
— Выполнение тестовых сценариев в каждом из которых:
— Система подготавливается для выполнения сценария. Поскольку каждый сценарий имеет предусловия надо подогнать систему под эти условия. Например если для сценария надо чтобы в системе бы пользователь создавший три заказа, надо как-то получить в базе денных пользователя и три его заказа.
— Выполняется тестовый сценарий через эмуляцию действий пользователя в браузере.
— Система возвращается в состояние, которое было перед выполнением сценария, фактически в состояние сразу после установки приложения
— Составление отчёта о качестве приложения
— Сборка инсталяционного пакета, содержащего приложения с известным качеством.

Даже если код тривиален, вы всё равно должны его тестировать.
Пару дней назад, Роберт Мартин опубликовал пост «Прагматичность TDD», (здесь лежит перевод — прим.переводчика) где он рассказал о том, что не тестируют абсолютно весь код. Среди исключительных ситуаций, когда не стоит применять TDD, дядя Боб упоминает написание GUI-кода, и я вижу смысл в таких утверждениях, но среди исключений есть парочка, на мой взгляд, нелогичных.

Человек — ужасно ленивая зараза. Нет, ну я не о вас, конечно! Ну что вы! Я так, о себе. О 99% человечества. Но не о вас, нет. Вы сами за себя решайте. Но вот те 99%, так уж вышло — ужасно ленивы. Кто-то это отрицает, кто-то мирится, кто-то борется. А лично мне кажется, что это такая же неотъемлемая черта нашего вида, как, например, две руки и две ноги. Можно убиваться, что у нас нет крыльев или жабр — а можно научиться хорошо пользоваться тем, что есть. Так же и с ленью. Зачем её отрицать? Надо её использовать по-полной. И вот тут, поскольку мы с вами имеем кое-какое отношение к ИТ, давайте посмотрим, как с этим обстоит дело в нашей профессии.

Итак, моя последняя запись: стартап-ловушка (здесь её перевод — прим. переводчика) наделала много шуму. Среди людей, выражающих согласие и поддержку, нашлась и группа людей, которая была категорически не согласна. Я не буду здесь резюмировать все разногласия, ибо в этом месяце я уже исчерпал свой лимит ругательных слов. Но одним альтернативным мнением я проникся и считаю нужным его обсудить.
Речь о старом конфликте «прагматизм против догматизма».

В сети описано несколько подходов к тестированию приложений, разрабатываемых для Android и поэтому интересует насколько специфично выглядит процесс тестирования своих приложений у Вас, уважаемые коллеги, в частности применяется ли TDD подход или сначала разрабатывается функционал приложения, а потом пишутся тесты? Выберите, пожалуйста один из вариантов ответов:

Идея данной заметки — как гипотезы — появилась уже довольно давно, и все как-то не получалось… Но вот «на днях» (к моменту публикации — уже неделях) увидел подтверждение своего предположения что называется «из первых рук» (см. Kent Beck's answer to Unit Testing: Did the notion of using setup() and teardown() methods in test fixtures originate from JUnit?) и решил-таки воплотить эту задумку.

Думаю, что все знают, что такое модульные тесты, все знают или, по крайней мере, слышали, что такое непрерывная интеграция, и многие программируют на C++. Но я столкнулся с тем, что в интернете не так много информации о том, как же это все объединить и заставить работать вместе. Эта статья является попыткой дать новичками пошаговую инструкцию, которая позволит сделать первый шаг в создании модульных тестов для C++ проектов и организовать покоммитный прогон модульных тестов при помощи CI сервера.
Update: План:

1. Напишем HelloWorld
2. Настроим сборку HelloWorld на Jenkins
3. Напишем модульный тест для HelloWorld
4. Настроим прогон модульных тестов на Jenkins

Внимание: много букв и скриншотов, половина из которых избыточны. Особенно для тех кто уже в теме.

Google Test — это фреймворк от Google для юнит-тестирования кода на С++. Общей архитектурой он слегка напоминает общепринятые boost::test и CppUnit, хотя слегка отличается в деталях (как по мне — в лучшую сторону). Большая обзорная статья этого фреймворка уже как-то пробегала на Хабре, но нынче она в каком-то побитом состоянии (код не отображается), да и кажется мне слишком сложной для начала работы. Поэтому я коротко опишу «Hello world» на Google Test, указав на несколько потенциальных проблем, с которыми вы можете столкнуться, используя Google Test при разработке под Visual Studio.

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

Однажды мне надоело, что исправление багов занимает у меня больше времени, чем разработка приложения, и в поисках путей решения я пришел к TDD — Test-driven development (Разработка через тестирование).

В это статье рассказывается как делать первые шаги в XCode 4.5, используя unit test-ы, при разработки приложений под IOS.

Статья предназначена для новичков, в ней не содержится информации для зубров разработки.

Coding Dojo (кодинг додзё) — это встреча, на которой программисты (а теперь все чаще и тестировщики) вместе бьются над какой-нибудь задачей. Помимо фана, разработчики занимаются тем, что принято называть Deliberate Practice — регулярная практика, целью которой является постоянное повторение какого-то упражнения с целью повышения навыка. Именно поэтому и появилось название Dojo, потому что

Додзё — это место, где мы дисциплинируем и совершенствуем себя, чтобы стать лучше.

Ну а под катом можно прочитать об истории появления, основные принципы и многое другое.

От переводчика. На Хабре довольно много статей, посвященных TDD. Но к сожалению в них нет подробной информации о том как внедрять TDD комплексно, на уровне компании. Как мне показалось, данная статья дает на это ответ и если вы поставили перед собой такую цель, то эта статья может вам пригодиться.

Я столкнулся с командами в нашей организации, которые пытаются внедрить Test Driven Development (TDD).Иногда одному или двум разработчикам удается применить его без посторонней помощи, но у большинства этого не выходит. Чтобы лучше понять проблему я провел опрос среди членов команды и обнаружили, что даже после обучения еще многое предстоит сделать. Эта стратегия была разработана, чтобы помочь любому внедрить TDD в организации, хотя некоторые из идей применимы лишь для средних и крупных компаний.

С моим первым опытом TDD на меня снизошло озарение. Последние 2-3 года со всех сторон атакует информация «TDD это хорошо», «Тебе нужно TDD», отчего мозг инстиктивно начинает противиться насаждаемой информации. До этого я ни разу в коммерческих проектах не практиковал TDD, но когда начал — все встало на свои места. Хочу показать одну интересную на мой взгляд точку зрения на автоматизированные тесты, которой еще ни разу ни от кого не слышал.

Многие слышали про Selenium WebDriver — один из самых популярных инструментов для написания приёмочных/интеграционных тестов.


Используя Selenium, мы очень быстро заметили, что нам раз от раза приходится писать один и тот же код, чтобы инициализировать браузер вначале, закрыть его в конце, делать скриншоты после каждого упавшего теста и т.д. (пруфлинк).

Поэтому мы решили выделить этот повторяющийся код в отдельную библиотеку. Так на свет появился Selenide.

Я, как и многие программисты, довольно много слышал и читал о практиках TDD. О пользе хорошего покрытия кода юнит-тестами — и о вреде его отсутствия — я знаю по собственному опыту в коммерческих проектах, но применять TDD в чистом виде не получалось по разным причинам. Начав на днях писать свой игровой проект, я решил, что это хорошая возможность попробовать. Как оказалось, разницу по сравнению с обычным подходом можно почувствовать даже при реализации простейшего класса. Я распишу этот пример по шагам и в конце опишу результаты, которые для себя увидел. Думаю топик будет полезен тем, кто интересуется TDD. От более опытных коллег хотелось бы услышать комментарии и критику.

В этой статье я хочу рассказать о тестировании iOS приложений и небольшой автоматизации этого процесса.
Под катом будут рассмотрены инструменты для модульного и функционального тестирования и приведены простые примеры.

Многочисленные статьи, посвященные TDD в общем и Unit-тестам в частности, как правило, оперируют довольно искусственными примерами. Например, давайте напишем функцию, которая складывает два числа и напишем для неё тест. Честно говоря, на таких примерах трудно оценить преимущества использования автоматизированных тестов.

Некоторое время назад мне подвернулся малюсенький проектик, который как будто специально создан для того, чтобы опробовать на нем методику проектирования, основанную на тестах. Результат применения поразил меня самого! Приглашаю под кат всех, кто еще сомневается в том, что нужно применять автоматизированные тесты в повседневной разработке.

Когда разработчики впервые открывают для себя прелести разработки через тестирование — это как переход в новый, лучший мир, где гораздо меньше стресса и незащищенности. Этот прекрасный опыт действительно стоит отпраздновать. Но осознание преимуществ тестирования — только первый шаг к просветлению. Самое сложное — понять что НЕ нужно тестировать.

Если новичку можно и не заботиться о том что не стоит тестировать в первый день, то на второй день ему бы лучше начать вникать в это. Люди — создания привычки, поэтому если вы начнете формировать плохую привычку избыточного тестирования с самого начала, то вам будет гораздо труднее избавиться от нее потом. А избавиться от этой привычки вы должны.

Я уже писал на Хабре о Codeception — фреймворке для тестирования приложений на PHP. Если вы никогда раньше не писали тестов для вашего приложения, вам обязательно стоит взглянуть на Codeception. Он очень прост в использовании и сделан специально, чтобы уберечь разработчиков от рутины.

Сегодня я хотел бы рассказать, какие фичи появились в проекте в последнее время, а также отвечу на пару популярных вопросов.