Ошибки, сложный материал, вопросы >
Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

Загляните в раздел «Обсуждение»:

  • задайте вопрос нашим менторам. Вы быстрее справитесь с трудностями и прокачаете навык постановки правильных вопросов, что пригодится и в учёбе, и в работе программистом;
  • расскажите о своих впечатлениях. Если курс слишком сложный, подробный отзыв поможет нам сделать его лучше;
  • изучите вопросы других учеников и ответы на них. Это база знаний, которой можно и нужно пользоваться.
Об обучении на Хекслете
JS: Продвинутое тестирование

Моки

В тестировании очень популярен "мокинг". Технически он похож на стабинг, и из-за этого их часто путают (специально или ненамеренно). Но всё же они служат разным целям и используются в разных ситуациях. Разберёмся, что это такое, и когда он нужен.

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

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

HTTP

import nock from 'nock';
import { getPrivateForkNames } from '../src.js';

// Предотвращение случайных запросов
nock.disableNetConnect();

test('getPrivateForkNames', async () => {
  // Полное название домена
  const scope = nock('https://api.github.com')
    // Полный путь
    .get('/orgs/hexlet/repos/?private=true')
    .reply(200, [{ fork: true, name: 'one' }, { fork: false, name: 'two' }]);

  await getPrivateForkNames('hexlet');
  // Метод `scope.isDone()` возвращает `true` только тогда,
  // когда соответствующий запрос был выполнен внутри `getPrivateForkNames`. 
  expect(scope.isDone()).toBe(true);
});

Это и называется мокинг. Мок проверяет, что какой-то код выполнился определённым образом. Это может быть вызов функции, HTTP-запрос и тому подобное. Задача мока убедиться в том, что это произошло, и в том, как конкретно это произошло, например, что в функцию были переданы конкретные данные.

Что даёт нам такая проверка? В данном случае мало что. Да, мы убеждаемся, что вызов был, но само по себе это ещё ни о чём не говорит. Так когда же полезны моки?

Представьте, что мы бы разрабатывали библиотеку @octokit/rest, ту самую, что выполняет запросы к GitHub API. Вся суть этой библиотеки в том, чтобы выполнить правильные запросы с правильными параметрами. Поэтому там нужно обязательно проверять выполнение запросов с указанием точных URL-адресов. Только в таком случае можно быть уверенными, что она выполняет верные запросы.

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

Функции

Моки довольно часто используют с функциями (методами). К примеру они могут проверять:

  • Что функция была вызвана, и сколько раз она была вызвана
  • Какие и сколько аргументов было передано в функцию
  • Что вернула функция

Предположим, что мы хотим протестировать функцию forEach. Она вызывает колбек для каждого элемента коллекции:

[1, 2, 3].forEach((v) => console.log(v)); // или проще [1, 2, 3].forEach(console.log)

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

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

test('forEach', () => {
  // Моки функций в Jest создаются с помощью функции jest.fn
  // Она возвращает функцию, которая запоминает все свои вызовы и переданные аргументы
  // Потом это используется для проверок
  const callback = jest.fn();

  [1, 2, 3].forEach(callback);

  // Теперь проверяем, что она была вызвана с правильными аргументами нужное количество раз 
  expect(callback.mock.calls).toHaveLength(3);
  // Первый аргумент первого вызова
  expect(callback.mock.calls[0][0]).toBe(1);
  // Первый аргумент второго вызова
  expect(callback.mock.calls[1][0]).toBe(2);
  // Первый аргумент третьего вызова
  expect(callback.mock.calls[2][0]).toBe(3);
});

С помощью моков мы проверили, что функция была вызвана ровно три раза, и ей, последовательно для каждого вызова, передавался новый элемент коллекции. В принципе, можно сказать, что этот тест действительно проверяет работоспособность функции forEach(). Но можно ли сделать это проще, без мока и без завязки на внутреннее поведение? Оказывается, можно. Для этого достаточно использовать замыкание:

test('forEach', () => {
  const result = [];
  const numbers = [1, 2, 3];
  numbers.forEach((x) => result.push(x));
  expect(result).toEqual(numbers);
});

Объекты

Jest позволяет создавать моки и для объектов. Делаются они с помощью всё той же функции jest.fn(), так как она возвращает конструктор:

const myMock = jest.fn();

const a = new myMock();
const b = {};
const bound = myMock.bind(b);
bound();

console.log(myMock.mock.instances);
// > [ <a>, <b> ]

Через этот мок можно узнать любую информацию обо всех экземплярах:

expect(someMockFunction.mock.instances[0].name).toEqual('test');

Преимущества и недостатки

Несмотря на то, что существуют ситуации, в которых моки нужны, в большинстве ситуаций их нужно избегать. Моки слишком много знают о том, как работает код. Любой тест с моками из чёрного ящика превращается в белый ящик. Повсеместное использование моков приводит к двум вещам:

  • После рефакторинга приходится переписывать тесты (много тестов!), даже если код работает правильно. Происходит это из-за завязки на то, как конкретно работает код.
  • Код может перестать работать, но тесты проходят, потому что они сфокусированы не на результатах его работы, а на том, как он устроен внутри.

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


Дополнительные материалы

  1. Jest: Mocking functions
  2. Mock aren't stubs

<span class="translation_missing" title="translation missing: ru.web.courses.lessons.mentors.mentor_avatars">Mentor Avatars</span>

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят менторы из команды Хекслета или другие студенты.

Для полного доступа к курсу нужна профессиональная подписка

Профессиональная подписка откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, даст возможность обращаться за помощью к менторам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.

Получить доступ
115
курсов
892
упражнения
2241
час теории
3196
тестов

Зарегистрироваться

или войти в аккаунт

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.

  • 115 курсов, 2000+ часов теории
  • 800 практических заданий в браузере
  • 250 000 студентов

Отправляя форму, вы соглашаетесь c «Политикой конфиденциальности» и «Условиями оказания услуг».

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Rambler
Логотип компании Bookmate
Логотип компании Botmother

Есть вопрос или хотите участвовать в обсуждении?

Зарегистрируйтесь или войдите в свой аккаунт

Отправляя форму, вы соглашаетесь c «Политикой конфиденциальности» и «Условиями оказания услуг».