Что не так с заглушками для модульного тестирования?

Я использую следующую терминологию (введенную Роем Ошеровым, автором книги «Искусство модульного тестирования»):

подделка называется заглушкой , если вы скажете ему подделать что-то в случае вызова метода с такими-то параметрами. Но если вы также убедитесь, что такой вызов действительно имел место или имел место ровно N раз, то такая подделка называется имитацией . Коротко. подделка - это заглушка, если вы не вызываете для нее Verify (), а затем это фикция.

Очевидно, вам нужно будет использовать заглушки в одних случаях и имитировать в других. Таким образом, резкая критика заглушек, вероятно, неправильна, и использование исключительно заглушек, вероятно, также неверно.

Если вы еще не начали использовать фреймворк для имитации (альтернативный термин: изоляционный фреймворк ), вам следует следить за ними и часто пересматривать свои варианты. Я очень быстро перешел от ручных mocks к NMock2 и Moq. Вот интересный опрос программистов, показывающий, что они используют. Ручные макеты / заглушки в меньшинстве, но не такая уж редкость.

Моки намного проще добавить. Они являются реальным экземпляром вашего класса, предварительно заглушенным с возможностью переопределения действия любого метода с минимальным шаблоном.

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

Сколько шаблонов вы получаете, когда закрываете класс? Как вы справитесь с этим, если ваш урок финальный? Вы шутите, чтобы сначала поместить заглушку в путь к классам, или вы используете другой источник?

Я рекомендую просто начать с имитаций - все проще.

Нет ничего плохого в использовании заглушек вместо моков.

Если вы хотите получить техническую информацию, моки - это "умные" объекты, ожидания которых можно проверить. Заглушки - это фиктивные объекты, которые возвращают предустановленные значения. См. Mocks Aren't Stubs .

Но многие люди (включая меня) предпочитают проводить тестирование состояния с помощью заглушек, а не тестирование поведения с помощью mock. Вы вставляете заглушку в тестируемый класс, вызываете метод, а затем проверяете состояние тестируемого класса. Это имеет тенденцию делать менее хрупкие тесты, чем утверждение, что внутреннее устройство класса вызывало метод X имитационного объекта с аргументом Y.

Я не думаю, что вы попадете в мир боли. Если вы еще не начали чувствовать боль, вероятно, вам еще не нужна структура изоляции / имитации. Когда и если вы это сделаете, наличие рукописных заглушек / подделок никому не повредит.

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

Мне очень нравится Moq ; Я считаю, что для создания заглушек проще использовать Rhino Mocks.

Моки и заглушки используются для проведения реального модульного теста. Вы просто имитируете все зависимости и модулируете свой класс изолированно.

В настоящее время я использую MOQ для имитации и создания заглушек.