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

Ну а если я много прототипирую и меняю код по 20 раз в месяц, даже если немного, то написание тестов к коду - просто бесполезная двойная работа, т.к. у меня и кейсы бизнес-логики, и кейсы кода постоянно меняются. Юнит тесты нормально писать к более-менее устоявшемуся коду, меняющемуся редко - т.к. когда код первичен. И то разумно требовать не 100% покрытия, а лишь основной части.

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

Каждый раз, когда сажусь писать тесты, в голове стойкое ощущение ненужной дурацкой работы. Особенно, если есть стремление к 100% покрытию.