Моки — 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
3. Nock: HTTP server mocking and expectations library for Node.js
4. Mock Service Worker

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

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