Thread by @mokevnin

Про TDD. Я часто пишу тесты до кода, но при этом не работаю по TDD. Почему? Небольшой тред

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

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

На практике же, в бекенд фреймворках или библиотеках все часто сводится к очень небольшому публичному апи (функция, маршрут, класс), протестировав которое, никогда больше не придется менять тест. При этом получается высокая гарантия работы и возможность легко менять внутренности

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

Дальше зависит от специфики. В библиотеках лучше писать тесты до кода почти всегда, это дешево и быстро, в бекенд фреймворках такое можно писать почти всегда без ущерба, а вот во фронтенде тесты до кода это мука. А tdd там просто злое зло, кроме либ и логики вне представления

Ну и просто интересно gist.github.com/jordelver/3818… (Кент Бек)
TDD wasn't working for me, at least not as I apply it in object languages. This has forced me to take a step back and rethink what is really essential about TDD and what is an artifact of the languages I have been using.