Когда ожидать и когда заблокировать?
Visual Studio автоматически создаст их. Я не рекомендую поместить их в управление исходным кодом. Были многочисленные времена, где файл СУ локального разработчика заставлял VS вести себя беспорядочно на том поле разработчиков. Удаление файла и затем разрешение VS воссоздать его всегда устраняли проблемы.
2 ответа
Множество фреймворков для фиксации сближают концепции макетов и заглушек до такой степени, что их можно считать функционально почти одинаковыми. Однако с концептуальной точки зрения я обычно стараюсь следовать этому соглашению:
- Mock : только когда вы явно пытаетесь проверить поведение тестируемого объекта (т. Е. Ваш тест говорит, что этот объект должен вызывать этот объект ).
- Заглушка : когда вы пытаетесь протестировать некоторую функциональность / поведение, но для того, чтобы заставить это работать, вам нужно полагаться на некоторые внешние объекты (т.е. ваш тест говорит, что этот объект должен что-то делать, но в качестве побочного эффекта он может вызвать этот объект)
Это станет яснее, если вы убедитесь, что каждый из ваших модульных тестов проверяет только одну вещь. Конечно, если вы попытаетесь протестировать все в одном тесте, вы можете ожидать всего. Но ожидая только того, что проверяет конкретный модульный тест, ваш код становится намного яснее, потому что вы можете сразу увидеть, какова цель теста.
Еще одним преимуществом этого является то, что вы будете немного более изолированы от изменения и получать более точные сообщения об ошибках, когда изменение вызывает перерыв. Другими словами, если вы незаметно измените какую-то часть своей реализации, у вас больше шансов получить только один тестовый пример, который покажет вам, что именно сломано, а не целый набор тестов, ломающих и просто создающих шум.
Edit : Это может быть яснее на основе надуманного примера, где объект калькулятора проверяет все добавления к базе данных (в псевдокоде) ...
public void CalculateShouldAddTwoNumbersCorrectly() {
var auditDB = //Get mock object of Audit DB
//Stub out the audit functionality...
var calculator = new Calculator(auditDB);
int result = calculator.Add(1, 2);
//assert that result is 3
}
public void CalculateShouldAuditAddsToTheDatabase() {
var auditDB = //Get mock object of Audit DB
//Expect the audit functionality...
var calculator = new Calculator(auditDB);
int result = calculator.Add(1, 2);
//verify that the audit was performed.
}
Итак, в первом тестовом примере мы ' повторное тестирование функциональности метода Add и нам все равно, произойдет событие аудита или нет, но мы знаем, что калькулятор не будет работать без ссылки auditDB, поэтому мы просто убираем его чтобы предоставить нам минимум функциональных возможностей для работы нашего конкретного тестового примера. Во втором тесте мы специально проверяем, что когда вы выполняете Add , происходит событие аудита, поэтому здесь мы используем ожидания (обратите внимание, что нас даже не волнует, каков результат, поскольку это не то, что мы тестируем).
Да, вы можете объединить два случая в один, выполнить ожидания и утверждать, что ваш результат равен 3, но затем вы тестируете два случая в одном модульном тесте. Это сделало бы ваши тесты более хрупкими (поскольку там '
Ну ... ИМХО, это может Не будьте проще: если ваш тест направлен на то, чтобы убедиться, что докладчик вызовет «Сохранить», выполните «Ожидание». Если ваш тест направлен на то, чтобы убедиться, что ваш Presenter будет корректно обрабатывать исключение, если Save выдает, создайте заглушку.
Подробнее см. в этом подкасте Хансельмана и Ошерова (автора The Art Of Unit Testing )