Проблема с TDD Практикуя TDD с 2004 года, столкнулся с проблемами, связанными со сложностью и дороговизной обслуживания наборов тестов. Столкнулся с сопротивлением со стороны умных разработчиков, которые ставили под сомнение ценность TDD.
Задачи в наборах тестов В наборах тестов было в три раза больше кода, чем в производственном коде, что приводило к замедлению разработки. При рефакторинге тесты часто прерывались с использованием макетов, что противоречило обещанию рефакторинга сохранить работоспособность кода.
Растущая устойчивость к TDD Появились методологии Holiday, которые не поощряли TDD из-за замедления процесса разработки. Программисты, использующие клейкую ленту, завоевали популярность благодаря быстрым решениям, несмотря на плохую инженерную практику.
Непонимание методов тестирования Подход, основанный на поведении, предложенный Дэном Нортом, делал акцент на тестировании поведения, а не методов или классов. Первоначальная идея Кента Бека также была сосредоточена на тестировании поведения, а не на деталях реализации.
Переориентация на первоначальные намерения В книге Кента Бека "Разработка, управляемая тестированием: на примере" рекомендуется сосредоточиться на тестировании API и избегать чрезмерного использования контейнеров IOC.
Архитектура портов и адаптеров "Гексагональная архитектура" предложила четкое разделение между логикой предметной области (внутри) и адаптерами (снаружи). Уровень портов служит интерфейсом для обмена данными между ними, в то время как интеграционные тесты обеспечивают надлежащее взаимодействие без подключения внутренних компонентов.