высмеивать модули es6 в модульном тесте - PullRequest
0 голосов
/ 25 мая 2018

Предположим, у нас есть файл (source.js) для тестирования:

// source.js
import x from './x';

export default () => x();

И код модульного теста очень прост:

// test.js
import test from 'ava';
import source from './source'

test("OK", t => {
  source();
  t.pass();
});

Но это сложная вещь.Файл "./x" не существует в тестовой среде.Поскольку это модульный тест, нам не нужно "./x".Мы можем в любом случае посмеяться над функцией "x ()" (используя sinon или что-то еще).Но инструмент модульного тестирования, ava, продолжает показывать: «Ошибка: не удается найти модуль» ./x'";

Есть ли способ запустить модульный тест без файла »./x"?

1 Ответ

0 голосов
/ 25 мая 2018

Для этого вам нужно переопределить сам процесс импорта.Существуют библиотеки для выполнения чего-то подобного - например, переопределение функции require с помощью proxyquire - но они заставляют вас вызывать их пользовательскую функцию для импорта тестируемого модуля.Другими словами, вам нужно отказаться от использования синтаксиса модуля ES6, чтобы использовать их.

Следует также отметить, что модули ES поддерживаются только экспериментально (и относительно недавно) в Node.Если вы путешествуете с Babel, вы не на самом деле , используя ES-модули.Конечно, вы используете синтаксис, но Babel переносит их в «эквиваленты» CommonJS, включая require вызовы и module.exports назначения.

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

Моя личная рекомендация - избегать прямого экспорта чего-либо, что вам может понадобиться.Поэтому функции типа x должны быть в статическом модуле, импортированном как import foo from './foo', и вызываться как foo.x().Затем вы можете легко заглушить его с помощью sinon.stub(foo, 'x').Конечно, для этого еще должен существовать файл './foo', но на самом деле он сводится к тому, насколько жестко вы хотите относиться к методам TDD по сравнению с тем, какую сложность вы готовы внести в процесс насмешек / заглушек.Я предпочитаю расслаблять первое, чтобы избежать второго, но в конце концов это ваше дело.

...