Комментарии 4
Спасибо автору, все ясно и четко, было интересно и полезно!
TDD разваливается как только у тестируемого объекта появляются внешние зависимости. Потому что до реализации тестируемого объекта мы практически никогда еще не знаем какие они будут и какими будут сценарии их использования объектом, а не зная этого мы не можем нормально написать тесты. Еще один фактор - я люблю и привык запускать тесте после каждого небольшого изменения или добавления в коде и видеть при этом все зеленое. Лично для меня нет разницы если, допустим, из сотни тестов красный один, десяток, или полсотни - "красный один" для меня эквивалентно "красное все" и требует немедленного исправления (или, в крайнем случае, временного отключения красного теста). Ну а при TDD до того как тестируемый объект будет реализован какая-то часть тестов будет красная. Я сам всегда пишу много юнит-тестов к своему, а часто и к чужому коду, но попытки использовать "канонический" TDD у меня всегда оканчивались фиаско.
Хочу еще вас предостеречь. Тема юнит-тестов, TDD, BDD и иже с ними на Хабре она очень скользкая, почти что на грани табуированной - есть риски нахватать минусов :)) Сам же ставлю вам плюсик :)
Согласен, что никогда не знаешь какие зависимости понадобятся, пока не сядешь за имплементацию. Можно итеративно подходить к этому: вначале расписать тест-кейсы на уровне `дёрнул метод и проверил результаты` и переходить к реализации. И каждый раз при добавлении новой зависимости в компонент мы ожидаем, что тест будет красным, а это уже побудит сходить в него и добавить эту новую зависимость
Не знаю, чем отличается BDD от обычных юз-кейсов (use cases). В данной же статье показано, как эти юз-кейсы автоматизировать с помощью основанной на Cucumber библиотеке для Python, а вовсе не про BDD. Или BDD и есть автоматизация старых добрых юз-кейсов?
Введение в BDD