Test Driven Development (TDD) - это не дизайн. Это требование, которое влияет на ваш дизайн. Так же, как если бы вы были обязаны быть потокобезопасными, это не дизайн. Опять же, это требование, которое влияет на ваш дизайн.
Если вы радостно игнорируете все другие проблемы проектирования и неукоснительно придерживаетесь правил TDD, не вините TDD, когда ваш код превращается в дерьмо. Это будет проверяемое дерьмо, но это будет дерьмо.
Хорошая вещь в тестируемом дерьме состоит в том, что это рефакторизованное дерьмо, поэтому для некоторых людей этого достаточно. Мы будем фантазировать только тогда, когда это необходимо. Другие ненавидят это и обвиняют TDD в этом. Это твое дело.
Проектирование на основе доменов (DDD) - это то, что вы делаете перед циклом рефакторинга TDD.
DDD - это попытка создать и сохранить пространство в коде, в котором специалист по предметной области, который в значительной степени не знает деталей системы, может понять, как управлять системой. Это делается путем абстрагирования и моделирования проблемной области известным способом.
Система DDD может иметь архитектуру, которая выглядит следующим образом:
Эта архитектура DDD имеет много названий: Clean , Onion , Hexagonal и т. Д.
Вот разрыв, который я вижу у многих людей, когда они смотрят на этот дизайн. Это не конкретно. Я могу следовать этой схеме и никогда не писал ничего, что вы видите на диаграмме здесь. Я вижу, что другие настаивают на том, что должен быть объект прецедента или класс сущностей. Это набор правил, которые говорят вам, с кем вы можете поговорить и как.
Вот и все. Следуйте правилам этого дизайна, и вы можете TDD свое маленькое сердце. TDD не волнует, с кем ты говоришь. Он заботится о том, что все, что делает что-то, может быть доказано, что оно работает или нет одним нажатием кнопки. Нет, что-то где-то сломано. Он говорит вам, что именно сломано.
Все еще расплывчато? Посмотрите на диаграмму Controler- Use Case Interactor- Presenterв правом нижнем углу. Вот три конкретные вещи, общающиеся друг с другом. Конечно, это DDD, но как добавить сюда TDD? Просто издевайся над конкретным материалом. Ведущий должен получать информацию. PresenterMockКласс был бы хороший способ проверить , что это то , чего вы ожидали получить. Передайте и драйв , как если бы вы были и у вас есть хороший способ для модульного тестирования , так как насмешка скажет вам , если он получил то , что вы ожидали получить.Use Case InteractorPresenterMockUse Case InteractorControllerUse Case Interactor
Хорошо посмотри на это. TDD доволен, и нам не пришлось возиться с нашим дизайном DDD. Как это случилось? Мы начали с хорошо отделенного дизайна.
Если вы используете TDD для управления дизайном (а не просто разработкой ), вы получаете дизайн, который отражает усилия, которые вы вложили в него. Если это то, что вы хотите, хорошо. Но это никогда не было то, для чего предназначался TDD. То, что в итоге этого не хватает, конечно, не вина TDD.
TDD не о дизайне. Если вам нужно внести изменения в дизайн, чтобы использовать TDD, у вас больше проблем, чем при тестировании.