Принципы TDD

Test-Driven Development (TDD)

Правило TDD: «As the tests get more specific, the code gets more generic» («Чем более конкретными становятся тесты, тем более общим становится код»).

Разработчик закладывает в тест своё понимание того, что должен делать код, который успешно пройдёт этот тест, — и только потом приступает к коду. Непрерывный рефакторинг позволит сохранить код настолько простым, насколько это возможно.

Цикл TDD

Когда нужен TDD?

• Если вам важно, чтобы код выполнял именно те задачи, которые вы перед ним ставите.

• Если вы пишете код, который планируете сохранить и использовать.

Преимущества TDD

Быстрая обратная связь.

Разработка небольшими блоками делает код более понятным.

Понятность предыдущего кода позволяет написать новые тесты быстрее.

Понимание картины будущего упрощает написание и тестов, и кода.

Это НЕ TDD

1. Тесты написаны после кода. Такие тесты проверяют только работоспособность готового кода, а не верхнеуровневые паттерны. Они не помогают улучшать архитектуру, это просто увеличивает кодовую базу.
2. Нет понимания Domain-Driven Design. Разработчик не думает о контексте бизнеса и не понимает, в чём смысл кода для бизнеса.
3. Используются фикстуры для данных (делают тесты хрупкими из-за зависимости на данных в фикстурах, их долго писать и в целом создают условия для более длинных итераций, делают назначение тестов неясным и усложняют модификацию самих тестов). Лучше использовать mock objects.
4. Тестирование слишком много проводится на макетных объектах, а не на реальных данных.

С помощью TDD нельзя разрабатывать

1. То, что требует тестирования не только на уровне кода. Например, разработка в области взаимодействия с физическими устройствами — для тестирования кейса «Звонит ли звонок» нужен микрофон.
2. То, что требует человеческой настройки и не определено в процессе написания теста (например, CSS).
3. То, что само по себе тестирует код — скрипты функциональных тестов и прочее.

Развитие парадигмы TDD

Behavior-Driven Development, BDD фокусируется не на тестировании, а на поведении пользователей. Обычные для TDD инструменты тестирования в BDD заменены на тестирование пользовательских историй. Код разрабатывается «снаружи внутрь» — от крупных  блабла к уточнению деталей.

Example-Driven Development, XDD по концепции близок к BDD. XDD берёт в качестве примеров правильного функционирования системы спецификации исполняемых файлов и ориентируется на них.

‍

Подробнее о TDD

Антипаттерны TDD

‍