Mocking Concepts — Серия тестирования №2

Ментальная модель вокруг насмешек

Что такое насмешка

Добро пожаловать во вторую статью из нашей серии о тестировании программного обеспечения! В последней статье были рассмотрены статические, модульные, интеграционные и сквозные тесты.

В этой статье мы рассмотрим:

Что такое издеваться?
Какие основные концепции стоят за этим?
Когда издеваться, а когда не издеваться?
Каковы наилучшие практики для насмешек?

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

Итак, что такое издевательство?

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

Эта «симуляция» может быть двух видов:

Поддельные данные
Поддельные взаимодействия

Поддельные взаимодействия

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

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

Эта фальшивая база данных считается фиктивным взаимодействием, потому что она имитирует (подделывает) что-то, с чем взаимодействует наша функция.

Поддельные данные

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

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

Для передачи входных данных нам нужны данные. И это не обязательно должны быть фактические данные из вашей реальной базы данных. Мы можем использовать фиктивные (поддельные) данные.

В этом примере мы создаем поддельного пользователя по имени Джо с идентификатором 1.

Когда издеваться

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

Во-первых, давайте взглянем на плюсы и минусы насмешек:

Плюсы

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

Быстрее, потому что (опять же) не нужно создавать все зависимости реальной базы данных;
Изолировано, потому что наши тесты все равно пройдут, даже если реальная база данных выйдет из строя.

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

Преимуществом этой изоляции является возможность отладки.

Без насмешек

❌ Тесты базы данных
❌ Платные тесты
❌ Тесты создания пользователей
❌ Тесты блога

Насмешка

❌ Тесты базы данных
✅ Платные тесты
✅ Тесты создания пользователей
✅ Тесты блога

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

Минусы

Меньше уверенности, потому что вы не используете реальные взаимодействия (или данные).

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

Серебряной пули не существует. Никакого волшебного ответа. Каждый случай нужно обдумывать индивидуально. От какой уверенности вы готовы отказаться?

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

Быстрые имитационные тесты;
Или медленные, настоящие сквозные тесты.

Я выбираю оба.

Как упоминалось в предыдущей статье, здесь мы проводим все виды тестов.

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

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

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

Лучшие практики пробного тестирования

Теперь, предположим, что вы уже решили использовать макеты, вот несколько лучших практик:

1. Только фиктивные типы, которыми вы владеете

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

2. Не имитируйте возвращаемые значения того, что тестируется

Задумайтесь об этом на секунду. Насмешка над возвращаемыми значениями нашего объекта тестирования даже не имеет смысла. Представьте, что вы пишете тесты для функции sum() и издеваетесь над ней, чтобы она всегда возвращала 3. Это не дает нам знать, работает ли наша функция на самом деле.

3. Не издевайтесь над всем

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

4. Используйте интеграционные тесты

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

5. Неудачные случаи тестирования

При создании макетов не забывайте моделировать ошибки и тестировать обработку ошибок. Вы даже можете добавить ожидания, что некоторые методы или вызовы API не должны выполняться в случае ошибки.

Не останавливайтесь здесь

Это все для понятий. В следующих статьях мы подробнее поговорим о поддельных данных и поддельных взаимодействиях.

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

И если ваша компания ищет удаленных веб-разработчиков, рассмотрите возможность связаться с моей командой и со мной. Вы можете сделать это через email, Twitter или Instagram.

Хорошего дня!

- Лукас