Разработка через тестирование для сложных методов, вовлекающих внешнюю зависимость

Question

Я выполняю сервисный контракт на сервис WCF.

В соответствии с TDD я написал тестовый пример, чтобы просто передать его с использованием жестко закодированных значений.

После этого я начал вносить реальную логику в реализацию моей службы. Фактическая логика опирается на 3-4 внешних сервиса и базы данных.

Что мне делать с моим исходным контрольным примером, который я написал? Если я оставлю его таким же, чтобы пройти тест, ему придется позвонить в несколько других внешних служб.

Поэтому у меня есть вопрос в целом, что мне делать, если я напишу контрольный пример для Business Facade сначала с использованием TDD, а затем, когда добавлю реальную логику, если она предполагает внешнюю зависимость.

Answer 1

Использование фальшивой структуры (с инверсией зависимостей или просто фабрикой), чтобы вы могли внедрить в объект ложные зависимости.Затем они могут затем просто вернуть готовые ответы и / или проверить, что класс использует зависимости, как вы предполагали.

В качестве примера, если ваш код вызывает хранилище для сохранения, нам не все равно,тест бизнес-метода, который репозиторий действительно сохранил в хранилище персистентности, только что он был вызван и, при необходимости, возвратил некоторые данные.Что вы на самом деле тестируете, так это как ваш код реагирует на то, что вернула зависимость, или если он был использован правильно, но не на фактическую функциональность зависимости

В идеале первый тест должен был представлять, как класс / методбудет работать и возвращать данные, поэтому тест будет по-прежнему действительным, когда вы закончите.