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

Question

Я только что посмотрел этот забавный YouTube-видео о модульном тестировании (это Гитлер с фальшивыми субтитрами, который разжигает свою команду за плохие юнит-тесты - пропустите, если у вас плохой юмор), где окурки получаются круглыми критика. Но я не понимаю, что не так с заглушками.

Я не начал использовать насмешливый фреймворк и не почувствовал боль от его использования.

Могу ли я когда-нибудь повредить миру, выбрав рукописные заглушки и подделки вместо насмешек (например, Rhinomock и т. Д.)? (используя таксономию Фаулера)

Каковы соображения при выборе между макетом и рукописной заглушкой?

Answer 1

В пеньках нет ничего плохого, есть место для пней, насмешек ... и шпионов. Все они "тестовые двойники", но с разными целями, как объяснено в Моксы и окурки не шпионы :

[...] Прежде чем двигаться дальше, я бы хотел уточнить и определить некоторые используемые термины здесь, который я первоначально обнаружил в xUnit Pattern Джерарда Месароса книга .

• Пустой объект - это объект-заполнитель, переданный в тестируемую систему. но никогда не использовал.
• Test Stub обеспечивает тестируемую систему косвенным вводом
• Тестовый шпион предоставляет способ проверить, что тестируемая система выполнена правильный косвенный вывод
• Макет объекта предоставляет тестируемой системе оба косвенных ввода и способ проверки косвенного вывода

[...] И вы можете позволить эту удобную диаграмму направляйте свои решения:

PS: Mockito - Новый Mock Framework на блоке тоже стоит того, чтобы его прочитать.

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Если вы хотите получить технические знания, макеты - это «умные» объекты с ожиданиями, которые можно проверить. Заглушки - это фиктивные объекты, которые возвращают заданные значения. См. Насмешки - это не заглушки .

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

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

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

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

Answer 5

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

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