Термин Test в тестовой разработке обычно интерпретируется как Unit Test, а не Integration Test, поэтому в чистом процессе TDD я бы не стал Считать стандартной практикой написание и запуск интеграционных тестов любого типа.
Это не значит, что не стоит писать и запускать интеграционные тесты - это просто не считается стандартной практикой TDD. Однако, если вы немного расширите область охвата, чтобы охватить гибкую разработку в целом, большинство гибких организаций считают стандартной частью своей практики поддержку и запуск автоматических приемочных тестов.
Интеграционные тесты, подобные тем, о которых вы спрашиваете, хорошо бы вписались в этот тип процесса. Возможно, вы не захотите делать это очень часто на своей машине разработки, но вам все равно придется делать сборку Continuous Integration (CI) или, по крайней мере, ежедневную сборку (в зависимости от сложности).
Когда вы рассматриваете их как приемочные тесты, наиболее разумно позволить вашему DI-контейнеру разрешить весь стек так, как он должен быть - то есть в этом случае не будет никаких насмешек: вы должны протестировать реальную сделку.
Суть, однако, такова: , если это работает для вас, сделайте это . Agile / Lean Development - это не догма, а постоянный поиск и применение техник, которые делают вашу команду максимально продуктивной. Хотя это может быть полезным для изучения ошибок и успехов других людей, вы должны в конечном итоге поэкспериментировать и измерить то, что лучше всего подходит для вашей команды.