Что такое Mocking?

Что такое Mocking?.

Ответ 1

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


Mocking в основном используется при модульном тестировании. Объект под тестированием может иметь зависимости от других (сложных) объектов. Чтобы изолировать поведение объекта, который вы хотите проверить, вы заменяете другие объекты с помощью mocks, которые имитируют поведение реальных объектов. Это полезно, если реальные объекты нецелесообразно включать в unit test.

Короче говоря, насмешка - это создание объектов, которые имитируют поведение реальных объектов.


Время от времени вы можете различать насмешливость, а не stubbing. Могут быть некоторые разногласия по этому вопросу, но мое определение заглушки - это "минимальный" имитируемый объект. Штук реализует достаточно поведение, чтобы тестируемый объект мог выполнить тест.

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

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

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

Ответ 2

На SO есть много ответов и хорошие сообщения в Интернете о насмешливости. Одно место, которое вы, возможно, захотите начать смотреть, - это сообщение Мартина Фаулера Mocks Are not Stubs, где он обсуждает множество идей насмешек.

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


В исходном вопросе упоминается TypeMock, поэтому я оставил свой ответ ниже:

TypeMock - это название коммерческой фальшивой структуры.

Он предлагает все функции бесплатных mocking frameworks, таких как RhinoMocks и Moq, а также несколько более мощных опций.

Будь или не нужно TypeMock очень спорно. - Вы можете сделать самое насмешливое вы когда-либо хотели с бесплатными библиотеками, насмехаясь, и многие утверждают, что способности, предлагаемые TypeMock часто приводят вас от хорошо герметичное исполнения

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

Ответ 3

Другие ответы объясняют, что насмехается. Позвольте мне провести вас через это с примером. И поверьте мне, это намного проще, чем вы думаете.

tl; dr Это подкласс исходного класса. У него есть другие данные, вводимые в него, поэтому вы избегаете проверки инъецированных частей и полностью фокусируетесь на тестировании остальной части кода.


Скажем, вы пишете приложение iOS и имеете сетевые вызовы. Ваша задача - проверить ваше приложение. Чтобы проверить/определить, работают ли сетевые вызовы как ожидаемые, НЕ ВАША ОТВЕТСТВЕННОСТЬ. Это другая сторона (команда сервера), чтобы проверить ее. Вы должны удалить эту (сетевую) зависимость и продолжить тестирование всего своего кода, который работает вокруг него.

Сетевой вызов может возвращать разные коды состояния 404, 500, 200, 303 и т.д. с ответом JSON.

Ваше приложение должно работать для всех из них (в случае ошибок ваше приложение должно выбросить ожидаемую ошибку). Что вы делаете с насмешкой, вы создаете "мнимые, похожие на реальные" сетевые ответы (например, код 200 с файлом JSON) и протестируйте свой код, не делая реального сетевого вызова и ожидая ответа сети. Вы вручную жестко задаете/возвращаете сетевой ответ для ВСЕХ видов сетевых ответов и смотрите, работает ли ваше приложение так, как вы ожидаете. (вы никогда не предполагаете/не тестируете 200 с неверными данными, потому что это не ваша ответственность, ваша ответственность заключается в проверке вашего приложения с правильными 200, или в случае 400, 500, вы проверяете, действительно ли ваше приложение выбрасывает правильную ошибку)

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

Для этого вы НЕ МОЖЕТЕ использовать свой исходный код (ваш исходный код не имеет предварительно вставленных ответов, верно?). Вы ДОЛЖНЫ добавить что-то к нему, вставлять/вставлять эти фиктивные данные, которые обычно не нужны (или часть вашего класса).

Итак, вы SUBCLASS исходного класса и добавляете все (здесь, если это HTTP-запрос HTTP, данные ИЛИ в случае сбоя, вы передаете правильный errorString, HTTPResponse), вам нужно это, а затем "проверить подкласс", т.е. издевавшийся класс.
Вы больше не тестируете исходный класс. Подделка/подкласс проверяется от имени исходного класса

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

Разумеется, вы тестируете каждый сетевой ответ отдельно.


Только для разработчиков iOS:

Очень хороший пример издевательства - это Практический протокол-ориентированный разговор Наташи Мурашев Просто пропустите минутку 18:30.

Мне очень нравится эта часть из стенограммы:

Поскольку это тестирование... мы хотим убедиться, что функция getиз Gettable называется , потому что он может вернуться, а функция теоретически может назначать множество продуктов из любой точки мира. Мы нужно убедиться, что он называется;

Ответ 4

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

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

С зависимостями, управляемыми mocks, мы можем легко проверить поведение метода, который мы закодировали. Это тестирование устройства.

Какова цель макетных объектов?

Mocks vs stub

Модульные тесты против функциональных тестов

Ответ 5

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

РЕДАКТИРОВАТЬ. Поскольку в первоначальной формулировке упоминается "тип насмешек", у меня сложилось впечатление, что это связано с TypeMock. По моему опыту, общий термин просто "насмешливый". Пожалуйста, не стесняйтесь игнорировать информацию, указанную ниже, на TypeMock.

TypeMock Isolator отличается от большинства других насмешливых фреймворков тем, что он работает над изменением IL на лету. Это позволяет имитировать типы и экземпляры, которые большинство других фреймворков не могут издеваться. Чтобы издеваться над этими типами/экземплярами с другими фреймворками, вы должны предоставить свои собственные абстракции и издеваться над ними.

TypeMock предлагает большую гибкость за счет чистой среды выполнения. Как побочный эффект того, как TypeMock достигает своих результатов, вы иногда получаете очень странные результаты при использовании TypeMock.

Ответ 6

Я бы подумал, что использование изоляционной среды TypeMock для издевательства будет TypeMocking.

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

Ответ 7

Если ваш макет связан с сетевым запросом, другой альтернативой является наличие реального тестового сервера. Вы можете использовать эту службу для генерации запроса и ответа для вашего тестирования. http://testerurl.com/

Ответ 8

Mocking генерирует псевдообъекты, имитирующие поведение реальных объектов для тестов