Это в чем-то реакция на https://www.youtube.com/watch?v=fPlBLlE8vOI .
В целом, TDD – это хорошо. Работа над ошибками у меня всегда проходит через TDD – сначала стараюсь написать тест, который не пройдет, потом исправить, чтобы прошло.
Работа над типичной функциональной задачей для бекенда: добавить новый http-endpoint или усложнить поведение текущего. Дальше рассматриваем этот сценарий.
В большинстве случаев, структура приложения уже есть, а сам функционал понятно как организовать. Так что можно сначала написать код, а потом покрывать тестами. На этом этапе важно не запускать код, а изначально тестировать его через тесты. Тогда нет потери времени на ручное тестирование.
Размер такого блока кода – по ощущениям, но стараюсь делать MR/PR раз в день, когда не получается, то раз в 2 дня.
При этом да, важно, как и в случае TDD, писать только необходимый код.
В чем плюс такого подхода? В том, что рефактринг происходит заметно быстрее. Не вижу смысла в том, что написанный код нужно сначала оттестировать, а затем рефакторить (когда это все происходить в рамках одного, максимум двух рабочих дней). Написал код, сразу отрефакторил, покрыл тестами.
Бывает, что после общения с разработчиками, которые будут использовать код, нужно так же немного изменить систему: структуру ответа, добавить какой-нибудь флаг. Если это делать с написанными тестами, то и рефакторинг, и изменения приводят к изменениям тестов, так что получается дольше (и морально тяжелее).
Вроде же рефакторинг не должен приводить к изменению тестов? Если мы стараемся полностью покрыть код тестами, то приводит.
В итоге, TDD – хорошо, особенно в сложных ситуациях или при поддержке, но для сокращения времени можно делать тесты сразу же после кодирования.