1. Введение:

Для бизнес-кода, который мы обычно разрабатываем, одна функция часто не является независимой. Она должна зависеть от других модулей, сторонних библиотек, баз данных, результатов взаимодействия сообщений и т. д.

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

В описанной выше ситуации внешней зависимости мы часто используем два метода для ее решения: один — Mock (симуляция), а другой — Stub (заглушка). Мы можем смоделировать ненормальное поведение этих внешних зависимостей (например: база данных недоступна, http-сообщение возвращает ошибку), а затем контролировать, какие ветки принимает тестируемая функция.

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

Во-первых, нам нужно знать, какие они? Во-вторых, нам нужно знать, в чем между ними разница?

Mock: означает симуляцию, которая означает создание структуры в тестовом пакете для удовлетворения интерфейса {} внешней зависимости. Заглушка: означает заглушку, которая относится к созданию фиктивного метода в тестовом пакете для замены метода в сгенерированном коде.

2. Примеры

Эти примеры относительно просты и предназначены только для демонстрации использования макетов и заглушек.

1. Ложный пример:

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

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

Примеры следующие:

Функция GetType изначально выполняла множество различных операций на основе разных входных параметров, включая сложение, вычитание и присвоение нуля.

После макетирования укажите тип GetType, чтобы выполнить только одну операцию «сложение».

Output:

Из вывода видно, что до макета было три операции, а после замены макета она стала операцией сложения.

2. пример заглушки:

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

Примеры следующих: (Примечание. Этот пример относительно прост и предназначен только для демонстрации использования заглушки.)

Функция GetType изначально выполняла множество различных операций на основе разных входных параметров, включая сложение, вычитание и присвоение нуля.

После заглушки укажите, что тип GetType выполняет только одну операцию: сложение.

Output:

Перед накоплением: функция-функция будет выполнять разные операции и выводить разные результаты в зависимости от значения входного параметра, а именно: брать 0; выполнять сложение: 2+5 = 7; выполнять вычитание: 5-1 = 4. После разбивки: функция-заглушка StubFunc возвращает только одну операцию «сложение», поэтому тестовый пример работает в соответствии с сложением независимо от типа входных параметров: 1+3 = 4; 2+5 = 7; = 6;

3. Сравнение макета и заглушки

1) И макет, и заглушка используют замену для реализации зависимостей в тестируемой функции, но макет использует замену интерфейса, а заглушка использует подстановку функции. 2) Реализация макета не является навязчивой для функционального кода, тогда как заглушка относительно навязчива. При реализации функциональных функций необходимо настроить некоторые функции обратного вызова для тестирования, которые здесь являются так называемыми заглушками. 3) Что касается метода управления заменой, если макет хочет поддерживать разные выходные данные, ему необходимо заранее реализовать разные коды ветвления и даже определить разные структуры макета для реализации. Такой макетный код станет макетным кодом, поддерживающим всю логику. При максимальном наборе ветвей сложность макетного кода станет выше; заглушка может хорошо управлять различными ветвями функции-заглушки, поскольку заглушка заменяет функцию, поэтому до тех пор, пока этот вид вывода необходимо использовать снова. , определите функцию, которая будет Да, эта функция может быть даже анонимной.

На основе приведенного выше анализа,Мы можем придумать способ,Пусть заглушка и макет будут объединены,Примеры следующие:

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

Output:

Судя по результатам выполнения тестового примера, когда функция-заглушка представляет собой «сложение», первые два варианта использования будут выполнять операцию «сложение», когда функция-заглушка — «вычитание», последний вариант использования будет выполнять операцию «вычитание»; .

Резюме: Судя по трем приведенным выше примерам, макет и заглушка имеют свои преимущества и недостатки, а комбинация макета и заглушки является очень хорошим практическим методом. Однако окончательный метод, используемый для разработки тестовых примеров, зависит от конкретной ситуации. сцена. (Примечание: Google предоставляет специальный модуль для модульного тестирования, который будет представлен в последующих главах.)