Итак, я достаточно новичок в модульном тестировании и макете в C # и .NET; Я использую xUnit.net и Rhino Mocks соответственно. Я - новообращенный, и я думаю, что пишу спецификации поведения, а не просто TDD. Бах, семантика; По сути, я хочу, чтобы автоматизированная система безопасности работала выше.
Хотя мысль поразила меня. Я получаю программирование на основе интерфейсов, и здесь есть преимущества, связанные с разделением зависимостей. Продано. Тем не менее, в моем наборе проверки поведения (он же модульные тесты ;-)) я утверждаю поведение по одному интерфейсу за раз. Как и в случае, одна реализация интерфейса за раз, со всеми его зависимостями вычеркнуты и настроены ожидания.
Подход, по-видимому, заключается в том, что если мы проверяем, что класс ведет себя так, как он должен, в отношении его взаимодействующих зависимостей и, в свою очередь, полагаются на то, что каждая из этих взаимодействующих зависимостей подписала тот же контракт качества, мы получим золотую награду. Кажется достаточно разумным.
Вернемся к мысли, хотя. Есть ли какое-то значение в полуинтеграционных тестах, где тестовое приспособление утверждает против единицы конкретных реализаций, которые связаны друг с другом, и мы тестируем его внутреннее поведение с помощью симулированных зависимостей? Я просто перечитал это и думаю, что мог бы сформулировать это лучше. Очевидно, что будет определенное количество «ну, если это добавляет ценность для вас, продолжайте делать это», я полагаю - но кто-нибудь еще думал об этом и получал от этого выгоды, перевешивающие затраты?