Ну да, сразу написать юнит-тест можно под относительно не сложную математическую функцию. Например посчитать площадь  треугольника или ещё что-то в таком духе.
А для более менее сложной бизнес-логики так же просто можно было бы, наверное, написать только функциональный тест, который уже совсем верхнеуровнего тестит (например API вызовы). Что бы к промежуточным слоям писать сначала тесты - это либо надо "на бумажке" всё спроектировать прежде чем код пилить. Или если у тебя какой-то фреймворк, и 98% решений под него делаются "под копирку", однообразно, и ты заранее хорошо знаешь что ты будешь писать и как это тестить.

Ну пока у меня с этим проблема (

Вернее если у меня есть TSR, то к нему я могу функциональный тест написать.

Если у меня есть код, то у нему могу написать юнит. С интеграционными пока тяжело. Ну как уже сказал, написать тест до ....

Зато на Джанге написал хелоуворд :-)

Ну все тебя уже не спасти)) будешь все писать на джанге

@ildaar с левел аппом тебя! Принимай соболезнования!

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

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

"Мелкие функции" не появляются из "воздуха" сами. Как правило это либо какие-то хелпер-функции нужные для другого, более сложного функционала, либо результат "рефакторинга", когда распухшие функции разделили или вынесли из них общий код.

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

А время на тдд считается по сравнению со временем девелопмента + написание тестов на уже заимплементированное, я ж в конце сообщения про это как раз и добавил, что общее время получается сравнимым

Вообще странно. Я пишу тест который падает. А после пишу метод который его делает пасс, но один тестовый случай не гарантирует, что метод рабочий.

Получается я должен подобрать максимально специфичный тестовый случай.

А кто сказал, что один тестовый случай, ты сразу все описываешь на которые хватает фантазии

Ты идешь по юзер стори, начиная с функционального теста типа:
Открыл браузер ввел url, получил стартовую страницу.
Но тут же логично сделать ввел неправильный url и получил 404..
Потом юнит тесты для вьюх и моделей соответственно

Когда ты "собаку съел", и в добавок у тебя фреймворк, который "палкой" заставляет делать всё в едином стиле, по единым патернам, то уже не так важно становится TDD у тебя или просто тесты. Ты уже заранее знаешь, что ты будешь в коде писать, какой будет у этого интерфейс и знаешь какие тесты у тебя будут.

У TDD без "собаки", "патернов" и в целом без детального проектирования есть заметный минус. Приходится не только код переписывать, когда ты понял что надо всё сделать по другому. Приходится ещё и тесты все заново писать. Конечно это не прям супер-минус для TDD, но знать про него надо.

Ну и есть методика проектирования через написание кода.
Так что я могу смело сказать, что я всё делаю через TDD. Ведь я не код сначала пишу, а потом тесты. Это я сначала проектирую систему через код. После этого пишу тесты. А потом, волшебным образом, оказывается что мне почти не надо писать код - он уже написался пока я проектировал систему. 😊

А есть еще практики анализа требований через написание кода, но там другое в конце оказывается :(

😂👍