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