TDD *

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

• Вступление
• Тесты и есть проблема!
  
  • Немного истории
  • Небольшая викторина
• Обзор TDD
  
  • Тесты — это формализованные требования
  • TDD поощряет хорошую архитектуру
  • TDD экономит время
  • Тесты — это лучшая документация
  • Немного выводов
• В чём же решение?
  
  • Несколько примеров
  • Немного про планы

Забавно, как всё меняется. Пятнадцать лет я свято придерживался принципов TDD (разработка через тестирование, или, как её раньше называли, подход test-first) или уж по крайней мере того взгляда, что разработчикам следует писать юнит-тесты. Но в последнее время я всё чаще говорю не «Это нужно затестить», а «Зачем вы писали этот тест?».

Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.

Новые технологии — новые надежды

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

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

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

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

Без использования unit-тестов и TDD очень легко выстрелить себе в ногу. С тестами и TDD сделать это намного сложнее, но если у вас получится, вы останетесь без ноги.

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

В этой статье я постараюсь объяснить о чем, собственно, разговор. Для чего нужно TDD и как его аккуратно использовать.

Что такое TDD в двух словах? — это написание разработчиком тестов до реализации функциональности.
По совету Роя Ошерова разобьем вопрос применимости TDD на два:

• Зачем писать тесты?
• Зачем писать тесты до реализации?

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

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

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

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

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

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

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

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

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

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

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

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