Поэтому и говорят, что тесты могут писать не только лишь все

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

Зачем вообще кому-то такое объяснять? Неужели это не очевидно?

когда сначала тесты, потом код

Следует сразу отметить, что при написании регрессионных тестов (или по русски тестов на уже написанный код), удостоверься что тесты не хуевые - очень сложн, потому что код как бы уже выполняет бизнес требования, и не понятно, как бы выглядел код «необходимый но не достаточный» для прохождения по написанным регресионным тестам

Поэтому TDD лучше чем все остальные способы тестирования

Только жуй кто умеет 🤣

Поэтому дядя Боб в одной из своих книг поясняет, что TDD не про "написать тесты, а потом код". Аля круговорот воды в природе, пишешь тест и код, прогоняешь, рефакторишь и так до тех пор, пока не будешь доволен

Я не очень умею в тдд

Потому что не всегда сразу понятно, что будет делать программа и как

Я как скульптор - набрасываю каркас, играюсь с интерфейсом и думаю, что могло бы лучше подойти. Иногда понимаю, что можно в разы проще сделать, чем изначально планировалось

Со схемы тогда или листка стоит начать.

Поэтому чистый ТДД считаю вымыслом

Иногда получается, иногда - нет

И интерес к схемам быстро пропадает

Тяга "сделать" пересиливает

Обычно я схему в голове рисую, фиксирую в памяти и воспроизвожу

На листке рисовать очень скучно)

+
в теории все красиво, на практике не идет

Я добавлю про тесты. Почему-то считается (судя по возгласам несогласных), что код с тестами = код + тесты, типа можно взять код и потом дописать к нему тесты. Так вот нет, TDD - это про умение писать ТЕСТИРУЕМЫЙ код сразу. Код, написанный с пониманием как он будет тестироваться - это другой код. Когда разработчик пишет пару "код + тест" - он делает больше, чем просто код, который потом можно прочитать, понять, и если надо - прикрутить тесты.

Подобно тому, как, цитирую

Структурное программирование накладывает ограничение на прямую передачу управления.
Объектно-ориентированное программирование накладывает ограничение на
косвенную передачу управления
Функциональное программирование накладывает ограничение на присваивание.

так вот, подобно этому разработка-через-тестирование накладывает ограничение на написание нетестируемого кода.