Что такое TDD

Что проверяют

Отличает ли тестировщик TDD как технику разработки от тестирования как процесса. Вопрос про кругозор и про границы ответственности: понимает ли кандидат, что цикл пишет разработчик, и как это меняет работу QA дальше по конвейеру.

Как отвечать

Основа это цикл red-green-refactor: сначала падающий тест на маленький кусок поведения, потом минимальный код, чтобы тест позеленел, потом рефакторинг под зелёными тестами. Порядок не формальность: тест, написанный первым, фиксирует требование и заодно проверяет собственную способность упасть.

Стоит сразу расставить роли. Юнит-тесты в этом цикле пишет разработчик, задача QA лежит выше: интеграционные и API-тесты, сквозные сценарии, приёмка. Рядом полезно назвать соседние практики ATDD и BDD, где пример на языке бизнеса формулируется до кода и становится критерием приёмки; вот тут тестировщик участвует напрямую, помогая собрать краевые случаи и превратить требование в проверяемые примеры.

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

Где спотыкаются

Ставят знак равенства между TDD и наличием юнит-тестов. Тесты, написанные после кода, повторяют его форму и часто просто фиксируют текущее поведение вместе с ошибками, а тест, который ни разу не падал, не проверен вовсе.

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

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