Обнаружение других объектов при выполнении TDD
Это означает, что «если первая половина выражения ложна, используйте вместо нее вторую половину».
Практически в этом примере это означает, что для hrs будет установлено значение hours-12, если только hours-12 равно нулю, и в этом случае значение hrs будет установлено на 12.
4 ответа
Не ищите однозначной связи между вашими тестами и вашими классами. Если вы решите ввести новый класс, пусть это будет рефакторинг, поддерживаемый исходным тестом, и добавьте тесты в соответствующем месте (где это зависит от конкретного случая), когда вы хотите добавить функциональность (или протестировать возможные варианты. чтобы скрыть то, что вы еще не тестировали)
Я бы добавил, что главный успех TDD - это войти в ритм красно-зеленого рефакторинга. Когда вы чувствуете пользу от этого ритма, вы начинаете его «понимать». Это не значит, что вы сочтете это полезным во всех случаях, но пока вы не почувствуете этот ритм, вы не сможете понять, что его сторонники любят.
И обычно (особенно в архитектурно сложных приложениях, например, n-уровневые приложения) некоторая предварительная разработка. Ничего не нарисовано на камне, но достаточно, чтобы у юнитов было куда двигаться. Конечно, архитектура может развиваться с помощью гибкой методологии, но общее представление о ландшафте должно присутствовать, если в архитектуре есть несколько уровней.
РЕДАКТИРОВАТЬ: (В ответ на комментарий). Следует ли тестировать новый класс самостоятельно? Не обязательно. Это зависит от того, разовьет ли класс собственное значение. Когда вы проводите модульное тестирование, вы тестируете часть функциональности. Это не интеграционный тест только потому, что задействованы два класса. Когда два устройства начинают взаимодействовать, это становится интеграционным тестом. Граница, о которой я обычно думаю, заключается в том, что если мне нужно настроить важное состояние в группе классов A для взаимодействия с группой классов B,
Проблема в том, что когда я прибыть в точку 6 и 7, в какой-то момент со временем я неизменно прихожу к вывод, что реализация I только что написанные должны быть делегированы другой класс.
Для реализации вашего дизайна лучше использовать другой класс - это дизайн, и в этом суть TDD. Так что это прекрасная вещь, и это не должно вас беспокоить.
Но это вас беспокоит. Так что делать? Помните, что делегирование другому классу - это рефакторинг; это то, что нужно сделать после шага 6, во время шага 7. Как только вы станете «зеленым», проведите рефакторинг для улучшения дизайна. У вас уже есть тесты для нового класса; они просто запрограммированы на вызов исходного класса. Это прекрасно. После извлечения класса и делегирования, если вам будет удобнее, чтобы тесты вызывали извлеченный класс напрямую: сделайте это. Никакого вреда. Если извлеченный класс начинает использоваться другими вызывающими абонентами, я бы порекомендовал его,
Когда я попадаю в такую ситуацию, я следую вашему решению №1. Продолжайте повторять, создавая столько классов, сколько считаете нужным, пока не получите коллекцию реализаций, которая вас устраивает. По мере накопления опыта вы обнаружите, что ваши проекты отражают ваш опыт, и такого рода вещи случаются не так часто.
Вы должны создать фиктивный класс. Единый интерфейс с предсказуемыми результатами. Таким образом, вы можете протестировать оригинал.
Позже вы можете повторить процедуру с новым классом.