Не ищите взаимно-однозначных отношений между вашими тестами и вашими классами. Если вы решите ввести новый класс, пусть это будет рефакторинг, поддерживаемый исходным тестом, и добавьте тесты в соответствующем месте (где это зависит от конкретного случая), когда вы хотите добавить функциональность (или для тестирования возможных ситуаций, которые вам нужны). чтобы покрыть то, что вы еще не тестировали).
Я бы добавил, что главный успех в TDD - войти в ритм красно-зеленого-рефактора. Когда вы чувствуете пользу этого ритма, вы начинаете его «получать». Это не значит, что вы найдете его стоящим во всех случаях, но пока вы не почувствуете этот ритм, вы не дойдете до того, что его сторонники любят в этом.
И обычно (особенно в архитектурно сложных приложениях, таких как n-уровневые приложения) существует некоторая предварительная конструкция. Ничего не набросано в камне, но достаточно, чтобы дать отрядам место, куда можно пойти. Конечно, архитектура может развиваться в гибкой методологии, но общее представление о ландшафте должно быть там, если в архитектуре есть несколько слоев.
РЕДАКТИРОВАТЬ: (в ответ на комментарий). Должен ли новый класс пройти тестирование самостоятельно? Не обязательно. Это зависит от того, развивает ли класс свою значимость. Когда вы проводите модульное тестирование, вы тестируете функциональность. Это не интеграционный тест только потому, что в нем участвуют два класса. Это становится интеграционным тестом, когда два блока начинают взаимодействовать. Граница, о которой я обычно думаю, состоит в том, нужно ли мне устанавливать значимое состояние в группе классов A для взаимодействия с группой классов B, и особенно если группа классов A вызывает группу классов B и что Меня интересует, как B реагирует на A, затем я смотрю на интеграционный тест.