Я тоже иногда использую описанный вами подход — и он не кажется мне плохим или бессмысленным. Очень часто он оказывается эффективным — например, когда требуется писать интеграционные тесты на готовый функционал.
Материалы я думаю вы без труда найдете — их завались по этой теме.
На мой взгляд самое главное следующее — для TDD требуется особый подход к мышлению во время написания кода. И именно этот подход делает его эффективным. Заключается он в том, что вы не пытаетесь полностью выстроить в голове работающий метод, который создаете. Вместо этого вы выделяете отдельные бизнес составляющие метода — и создаете их поэтапно.
Профит в том, что у человека не хватит ума охватить целиком весь бизнес даже довольно простого метода (хотя он думает иначе разумеется) — отсюда появляются проблемы при дальнейшей поддержки метода, баги, переусложненные методы, код который имеет низкое или нулевое бизнес значение и т.д.
Например вы делаете метод который вычисляет корень из числа… Напишите простой тест подавая туда число 4 и ожидая что на выходе будет 2. Далее имплеминтируете функционал добиваясь чтобы тест прошел.
Но ничего лишнего там писать не стоит. Потом пишите следующий тест например на реакцию на отрицательные значение — далее имплементируете функционал. И так далее.
То есть это метод мышления. Самому к этому прийти не получится — самый лучший вариант — нанять человека который уже это умеет и научится сидя с ним в паре. Если это не возможно — попытайтесь понять стиль такого кодирования использую пособия на реальных ситуациях вроде
этого.
Вот
тут описаны проблемы при использовании подхода.
TDD — это не метод тестирования — а метод разработки. Он требует архитектурной готовности системы.
При тестировании модуля (например метода или класса) обязательно избавьтесь от всех внешних зависимостей путем мокирования.
Лучше ввести это как жесткое правило — потому, что оставлять такие зависимости можно только в редких случаях и когда вы уже прошарены в теме и что называется знаете — где правила можно нарушать.
Не ленитесь разрабатывать по шаблону — соблюдая мельчайшие и даже самые странные правила — даже если вы видите потерю эффективности — и со временем вы научитесь применять данный инструмент.
Простой
Простой
Простой
