jest.mock
действительно сложная вещь, так как она должна быть выполнена до того, как любой import
действительно запустится. Таким образом, есть некоторые ограничения :
Ограничение фабричного параметра заключается в том, что, поскольку вызовы jest.mock () поднимаются в начало файла, это невозможно сначала определить переменную, а затем использовать ее на фабрике. Исключение составляют переменные, которые начинаются со слова «макет». Вы должны гарантировать, что они будут инициализированы вовремя!
Я не знаю, почему даже после переименования кода с comp
на mockComp
произошел сбой, пока я не удалил __esmodule: true
. Итак, это передается мне:
[
{ path: 'comp1', mockComp: () => <div>1</div> },
{ path: 'comp2', mockComp: () => <span>2</span> },
].forEach(({ path, mockComp }) => {
jest.mock(path, () => mockComp);
});
В любом случае, даже если вы находите способ модуля равным esModule
и код был передан, я по-прежнему считаю, что наличие отдельного jest.mock()
для каждого модуля лучше поддерживается, чем итерация более конфиг. По крайней мере, действительно легко добавлять, удалять и смешивать встроенные макеты наряду с автомоками jest.mock('module1');
, основанными на коде в папке __mocks__
(в отличие от подхода с forEach
и объекта конфигурации)