Другие ответы объясняют, что такое насмешка. Позвольте мне рассказать вам об этом пример . И поверьте мне, на самом деле все гораздо проще, чем вы думаете.
tl; dr Это подкласс исходного класса. В него вставлены другие данные, поэтому вы избегаете тестирования вставленных частей и только сосредотачиваетесь на тестировании остальной части кода.
Допустим, вы пишете приложение для iOS и выполняете сетевые вызовы. Ваша задача - протестировать ваше приложение. Тестировать / определять, работают ли сетевые вызовы должным образом, НЕ ВАША ОТВЕТСТВЕННОСТЬ. Это обязанность другой стороны (серверной команды) проверить это. Вы должны удалить эту (сетевую) зависимость и все же продолжать тестировать весь свой код, который работает вокруг it.
Сетевой вызов может вернуть различные коды состояния 404, 500, 200, 303 и т. Д. С ответом JSON.
Ваше приложение должно работать для всех из них (в случае ошибок ваше приложение должно выдать ожидаемую ошибку). Что вы делаете с насмешками, так это то, что вы создаете «мнимые - похожие на реальные» сетевые ответы (например, код 200 с файлом JSON) и тестируете свой код без ', совершая реальный сетевой вызов и ожидая ответа вашей сети. ». Вы вручную жестко кодируете / возвращаете сетевой ответ для ВСЕХ типов сетевых ответов и смотрите, работает ли ваше приложение так, как вы ожидаете. (вы никогда не принимаете / не проверяете 200 с неверными данными, потому что это не ваша ответственность, вы должны проверить ваше приложение с правильными 200, или в случае 400, 500, вы проверяете, правильно ли выдает приложение)
Это создание воображаемого, похожего на реальное, называется насмешкой.
Для этого вы не можете использовать свой исходный код (исходный код не имеет предварительно вставленных ответов, верно?). Вы должны добавить что-то к этому, вставить / вставить те фиктивные данные, которые обычно не нужны (или часть вашего класса).
Таким образом, вы подкласс исходного класса и добавляете все, что вам нужно (здесь, например, сетевой HTTPResponse, данные ИЛИ в случае сбоя, вы передаете правильную errorString, HTTPResponse), что вам нужно, а затем 'тестируете подкласс 'то есть высмеянный класс.
Вы больше не тестируете оригинальный класс. Поддельный / подкласс тестируется от имени исходного класса
Короче говоря, насмешка над упрощением и ограничением того, что вы тестируете, а также заставляет вас кормить то, от чего зависит класс. В этом примере вы избегаете проверки сети сами по себе и вместо этого проверяете , работает ли ваше приложение, как вы ожидаете, с введенными выводами / ответами —— насмешливо классы
Само собой разумеется, вы проверяете каждый сетевой ответ отдельно.
Теперь вопрос, который я всегда думал, заключался в следующем: контракты / конечные точки и, в основном, ответ JSON моих API постоянно обновляются. Как я могу написать модульные тесты, которые принимают это во внимание?
Более подробно об этом: скажем, для модели требуется ключ / поле с именем username. Вы проверяете это, и ваш тест проходит.
Через 2 недели сервер меняет имя ключа на id. Ваши тесты все еще проходят. право? или нет?
Это обязанность разработчика бэкэнда обновлять макеты. Должно ли быть частью нашего соглашения, что они предоставляют обновленные макеты?
Ответ на вышеуказанный вопрос заключается в следующем: модульные тесты + ваш процесс разработки в качестве разработчика на стороне клиента должен / будет отлавливать устаревшие смоделированные ответы. Если вы спросите меня, как? хорошо ответ:
Наш кондиционерРеальное приложение может выйти из строя (или не потерпеть неудачу, но не иметь желаемого поведения) без использования обновленных API ... следовательно, если это не удастся ... мы внесем изменения в наш код разработки. Что снова приводит к провалу наших тестов ... которые мы должны исправить. (На самом деле, если мы хотим правильно выполнить процесс TDD, мы не должны писать какой-либо код для поля, пока мы не напишем для него тест ... и увидим, что он не пройден, а затем перейдем к написанию фактического кода разработки для него.)
Все это означает, что бэкэнд не должен говорить: «эй, мы обновили макеты» ... это в конечном итоге происходит через разработку / отладку вашего кода. ّ Потому что это все часть процесса разработки! Хотя, если бэкэнд даст вам надуманный ответ, тогда будет проще.
Весь мой смысл в этом заключается в том, что (если вы не можете автоматизировать получение обновленного поддельного ответа API), требуется некоторое человеческое взаимодействие, например ручное обновление JSON и проведение коротких собраний, чтобы убедиться, что их значения на сегодняшний день станет частью вашего процесса
Этот раздел был написан благодаря неспокойной дискуссии в нашей группе по встрече CocoaHead
Только для разработчиков iOS:
Очень хороший пример насмешек - это Практический протокол-ориентированный доклад Наташа Муращева Просто перейдите к минуте 18:30.
Мне очень нравится эта часть из стенограммы:
Поскольку это тестирование ... мы хотим убедиться, что функция get
из Gettable вызывается , потому что он может вернуть и функцию
теоретически может назначить массив продуктов питания из любого места . Мы
нужно убедиться, что он называется;