когда вы пишите тест вы хотите знать если вдруг что-то пойдет не-так. Вы используете интерфейс, вы уверены что фунцкция этого интерфейса всегда делает то, что обещает по документации? А вы уверены что это будет так завтра и через год? Вы уверены что ваш код правильно реагирует на ответы которые приходят на ваши запросы по API? А как поведет себя код если формат ответа изменится? Все эти "а что-будет если" не из любопытства и духа экспериментаторства а от неизвестности и неуверенности.
Когда ты ставишь свой код на "сигнализацию", стресса и неуверенности становится меньше, а информации больше. Можно проводить операции над кодом (рефакторинг) будучи уверенным, что если заденешь жизненно важный орган тебе об этом заморгает лампочка.
Про ТДД ничего не могу сказать, мне тяжело думать шиворот-навыворот. Стремиться к этому наверно нужно, потому, что если ты можешь начать с тестов то значит спецификация у тебя жесткая, отлично закодокументированая, архитектура четкая - но в жизни к сожалению бывает и иначе, там где сначала пилим как придется, посмотрим что получится, и если это понравится заказчику - доведем до ума.
П.С. помню как-то давно, когда только начинал изучать junit попробовал ради интереса написать на простенький класс-коллекцию тесты. Во-первых их получилось больше, чем мне казалось возможным на первый взгляд. Во-вторых, я не успел отъехать и на пятьсот строк кода, как уже тесты местами покраснели. Значит что-то задел и совершенно не обратил внимания. А казалось ну что можно напортачить в десяти классах. Можно.
