плюс код тестов отражает первоочередные кейсы, которые вы решить хотите

этот как формальный повод задуматься -  что писать-то будем, перед тем как это делать. чтобы было как можно меньше подхода "делай ->  думай"

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

Вот далеко не всегда это так. Этот подход рождает другую проблему: придумываешь шикарный api, а потом либо тупо не можешь его реализовать в разумные сроки, либо понимаешь что 2/3 этого api тебе вообще не нужны. А тесты уже написаны, время потрачено..

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

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

в целом это подход, тут надо выбирать как вам удобнее, не для всех задачь TDD уместен, но иногда от него есть ощутимая польза

а к подходу можно привыкнуть и потом кажется что и писать по другому не умеешь.. ну скорее просто нехочется

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

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

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

АПИ эволюционировать кстати может тоже через тесты=) ну тоесть ты писал-писал его два дня, начал писать тесты и понял что пользоваться им неудобно и стоит сделать первое, второе третье..

Напротив, TDD оправдан при большом количестве джунов. Опытным разработчикам это нафиг не сдалось.

Если в код вносятся изменения, условно новый кейс, который должен сработать при определенных условиях, как убедиться быстро, что все ок? Правильно - unit тесты. А тесты написанные опосля как правило гггг по причине того, что в большинстве случаев девелопер мыслит в рамках задачи не забегая вперед. А уж после завершения разработки менять свой код он не будет, что бы можно было накинуть тест. Да камон, накидал тесты, не надо в дебаге сидеть. Задевелопил, запустил юниты и пошел кофе пить))))

То есть тут не должно быть корреляции между тем джун или не джун. В долгосрочной перспективе затраты на TDD окупаются;)

если код не на выброс

Кажется, как раз против этого заблуждения придумано тестирование

Программисты любят, когда  правила простые и детерминистические. Посчитал джунов, перемножил на % покрытия кода, вычел количество багов, сравнил со значением из таблицы Брадиса - и понятно сработает TDD или нет.

В фомуле не учитывается время разработки. Вот будут эти джуны месяц писать простейший код, накрутят там 100500 абстракций на ровном месте, но покрытие 100%! TDD нельзя считать единственно-верным процессом разработки качественного ПО и процент покрытия кода юнит-тестами не показатель качества этого кода. Если не верите, посмотрите процент покрытия тестами ядра linux :)

За других не скажу, я не считаю.

По поводу тестирования бд, мне когда то вот этот доклад сильно помог - https://youtu.be/5hBOIJfve2o

Не надо путать тестирование как таковое и TDD.