Это как executable specification

как по мне эти все тдд это метод "разделяй и влавствуй". Оч хорош чтобы раздать многим командам и просто человекам. Никто толком не знает что он пилит, и зачем. Второй момент - защита исполнителя и закащщика. Все в рамках оговоренных условий и требований. Т.е. на руках чоткое тз фактически.

Сильно мелко мыслишь.

Ммм... Ты оч сильно не о том.

Простой пример, есть функция/метод/класс у которого несколько веток повеление (как вариант, валидация и ексепшен, возврат значения) вот тестом и описываешь все пути, а потом пилишь реализацию

На чистых функциях хорошо тренироваться

если тесты и реализацию пишет 1 и тот же человек, нет никакой разницы напишет он их до, или после реализации. Вот вообще.

В TDD всё очень просто, вы когда код пишете, дебажитесь? Останавливаете программу в определенном месте, что-бы визуально проверить результат? Или в базу залазите, посмотреть что сохранилось? Или тупо формочку руками заполните в браузере? Всё вы это делаете на протяжение написания кода.  Но все эти проверки не остаются. Делайте тоже самое, только проверки не визуально, а пишите программу для проверки.
Я вообще браузер не открываю, у меня тест есть

Вообще есть. Когда пишешь тест после, есть не нулевая вероятность подогнать тест под реализацию

Это тест first. Tdd один тест - путь за раз.

Не после!!! Ты можешь писать код три недели а потом посмотреть, работает он?

так а что помешает подогнать тест написанный до, после того как запилил реализацию? :)

Я и пытался объяснить, зачем писать тест ДО реализации

Ничего не помешает. Просто цели преследуются разные

Сколько часов вы можете писать, не разу не проверив, запускается или нет? Новички дрочат браузер после каждой новой строки

Friendly fire, bro

дебаг после реализации задачи конешь

Отличие, что не браузер дрочишь, а phpunit

в симфе подругому и не получится. Пока пазл не сложится его не запустишь 🤣

Привет апдейты задачи. И перепроверки того, что уже работало