TDD *

Зачем писать тесты? Когда их писать? Когда их не писать? Хабр был и остается неравнодушен к этим и другим вечным вопросам, и не один хабровчанин провел бессонную ночь, придумывая убедительные на них ответы (чтобы оппоненты, наконец, заткнулись).

Я решил взять противника не умением, а числом, и поэтому вот вам 19 причин, по которым писать тесты все-таки стоит (в хронологическом порядке). Итак, тесты

Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.

Но я думаю, что одна из главных причин заключается в том, что люди не знают, с чего начать. Вот прочитал я статью про юнит-тесты, понравилось; решил, что надо бы когда-нибудь попробовать. Но что дальше? С чего начать? Как придумывать все эти требования, как называть тест-методы?

В последнее время набирает популярность тенденция превращать юнит-тесты в BDD-спецификации, то есть говорится о том, что хороший юнит-тест должен не тестировать что-то, а описывать поведение программы. Но как описать это чёртово поведение; откуда брать вдохновение, чтобы придумать названия для всех этих тест-кейсов?

Об этом и пойдёт речь:

Один из самых частых ответов на вопрос «Почему я не пишу юнит-тесты» — это вопрос «А кто напишет тесты для моих тестов? Где гарантия, что в моих тестах тоже не будет ошибки?», что свидетельствует о серьёзном недопонимании сути юнит-тестов.

Цель этой заметки — коротко и чётко зафиксировать этот момент, чтобы больше не возникало разногласий.

Итак, юнит-тест — это

Я глубоко верю в методику TDD (разработка через тестирование), так как видел на практике пользу от неё. Она выводит разработку ПО на новый уровень качества и зрелости, хотя она до сих пор не стала повсеместно распространённой. Когда наступает момент выбора между функциональностью, временем и качеством, всегда страдает именно качество. Мы обычно не хотим потратить больше времени на тестирование и не хотим идти на уступки в количестве выпускаемой функциональности. Если вы не планировали использовать методику TDD с самого начала проекта, то потом очень трудно перейти на неё.

Все мы слышали

Я только что получил следующее письмо, которым хочу поделиться и ответить на него публично.

«Я не использую эту методологию (TDD) из-за того, что главный для меня вопрос остается без ответа. Я знаю, что использование TDD уменьшает количество багов, но что насчет времени, необходимого при работе по этой методологии?
Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD — уменьшается, увеличивается или остается неизменным.
Надеюсь, вы сможете ответить, так как TDD и BDD меня очень интересуют.»

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

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

Часто ли у так бывает, что вы встречаете плохой код и мысленно ругаете автора?
А потом приходите к выводу, что код не так уж и плох, и автора ругали зря… Но осадок-то остался!

В общем, медитировал я давеча перед монитором, и посетил меня

Видео с живой демонстрации техники «ping-pong programming» (разновидность парного программирования), показанной на встрече DevClub в сентябре 2009 года:

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

Компания SUN даже придумала специальный формат javadoc — «стандарт для документирования классов Java». В моей практике было совершенно обычным явлением, когда какой-то код не проходил Code Review, потому что в нём у некоторых методов отсутствовали комментарии.

Я утверждаю, что этот подход устарел, и сегодня я расскажу, почему комментарии — это зло.

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

В этом видео я разрабатываю приложение с помощью TDD на языке C#. Кроме демонстрации того, как надо писать модульные тесты, я постарался показать, как работает TDD на уровне приложения в целом.

При разработке применил принцип инверсии зависимости, а также использовал IoC-контейнер.

Исходники проекта написанного с помощью TDD. Visual Studio 2008/C#
Для написания тестов использована библиотека xUnit, для создания mock-объектов – Moq.

---

На очередном собеседовании, спрашивая о TDD, я пришел к выводу, что даже основные идеи разработки через тесты не поняты большинством разработчиков. Я считаю, что незнание этой темы – большое упущение для любого программиста.

Мне задают много вопросов про TDD. Из этих вопрсов я выбрал ключевые и написал на них ответы. Сами вопросы вы можете найти в тексте, они выделены курсивом.