Когда-то немножко писал про TDD в целом. По-прежнему считаю методику очень годной. Особенно когда каждый раз начинаешь плясать от Feature/Integration test, а не от Unit test (что было бы все-таки уныло). Поэтому постоянно, когда есть возможность, её применяю.
Помимо прочего, со временем становится очевидным еще одно важное свойство TDD. А именно — методика позволяет тебе, так сказать, ехать в полосе, видеть свет в конце тоннеля, и в то же время не дает разгуляться безудержной фантазии там, где это противопоказано.
Например. Делаем мы, скажем, набор классов с наследованием, понадобится фабрика, дерево подклассов, перегруженные функции, инъекции зависимостей и все такое. Наиболее правильным (и с точки зрения TDD тоже) представляется есть этого слона по кусочкам:
- Сделать первый подкласс, добиться чтобы он выполнял свою функцию (сразу после написания теста на этот подкласс, разумеется).
- Сделать второй подкласс, добиться чтобы и он работал.
- Посмотреть, что между ними общего, провести рефакторинг, вынести общие места в базовый класс, или создать еще один слой абстракции.
- Убедиться что после рефакторинга всё по-прежнему работает.
- Повторить с пункта 2.
- Когда задача 1–5 решена, провести еще один рефакторинг, добавить инъекции зависимостей, дописать интерфейсы к конкретным сервисам и т.п.
Однако неуемное воображение постоянно заставляет разработчика, еще не доделав 2, сразу переходить к 4. Потому что мозг видит потенциально общий метод в подклассе и немедленно говорит: — так, это мне нужно будет еще в тех трех классах, но нужно будет учесть еще два нюанса, щас мы с тобой такую абстракцию забабахаем!
Начинает, в общем, много лишнего думать мозг, а подкласс, над которым мы собственно начали работу, так и остается недоделанным. Потому что мозгу очень интересно, он очень хочет сразу решить сложную задачу. И не думает о том, что возможно если мы сначала сделаем все нужные подклассы, и они будут тестируемые, увидеть и отрефакторить общее место будет гораздо проще. А проверка, что рефакторинг удался, вообще произойдет автоматически, благодаря тестам, которые к этому моменту уже будут написаны.
И если предаться полету фантазии, то через какое-то время можно обнаружить набор наскоро написанных неоттестированных классов, которые в процессе проверки и отладки, очень вероятно, придется переделать, и не один раз.
Вот чтобы этого не было, помогает обозначенный эффект TDD: консолька как бы говорит — пока у тебя красные тесты, пиши то что тесты говорят! А помечтаешь когда всё исправишь.
