Как вы можете запускать тесты для версии X и версии Y библиотеки, с реальными примерами тестирования React 16 и React 17
С выпуском React 17 многие разработчики библиотеки React задались вопросом:
«Должен ли я с этого момента тестировать только React 17, или, может быть, мне следует придерживаться React 16, пока версия 17 не будет более широко принята сообществом?».
Я наверняка попал в такую ситуацию с моей библиотекой Почему ты рендерил.
Я решил найти способ протестировать обе версии, поскольку моя библиотека занимается исправлением React (не пытайтесь делать это дома: P) и работает немного по-разному для каждой из версий.
Кстати, если вам понравилась статья,
дайте мне знать, хлопнув в ладоши примерно 50 раз: P
Первый путь: псевдонимы пряжи
Это тот подход, которым я решил воспользоваться в конце концов.
Вы можете найти полный пример в Почему вы сделали рендеринг в версии 6.0.3.
Что я сделал, так это добавил библиотеки React 16 как зависимости с псевдонимом пряжи:
В результате yarn устанавливает react
, react-dom
и react-is
версии 16 вместе с их пакетами версии 17 в node_modules
:
Теперь нам нужно только убедиться, что при наличии определенной переменной ENV Jest использует правильную версию библиотеки.
Один из способов - использовать moduleNameMapper в jest.config.js
:
И теперь оба теста можно запустить примерно с помощью следующего скрипта npm:
"test:react-17": "jest --config=jest.config.js", "test:react-16": "USE_REACT_16=true jest --config=jest.config.js", "test": "yarn test:react-17 && yarn test:react-16"
Вот и все!
Но иногда мы хотели бы немного больше контроля над издевательством -
Manual Mocking
Мы также можем вручную смоделировать зависимости. Это может быть полезно в более сложных случаях, когда мы хотели бы иметь больший контроль над псевдонимами пакетов.
Я использовал этот подход в Почему ты сделал рендеринг в версии 6.0.2.
Конфигурация setupFilesAfterEnv определяет список файлов, запускаемых перед каждым тестовым файлом. Устанавливаем его на запуск jestSetup.js
:
где jestSetup.js
:
Но обратите внимание, что нам также нужно имитировать react-dom/test-utils
(в строке 10) и любой другой конкретный импорт. Вот почему я решил использовать подход moduleNameMapper
, о котором я упоминал ранее.
Этот подход дает нам немного больше контроля, но первый способ быстрее и понятнее.
Другой способ: отдельная папка
На самом деле это первый способ, который действительно сработал для меня. Мне он не понравился, потому что он казался слишком хакерским и уязвимым. Но я думаю, что мы можем многому научиться, если поймем, как это работает. Я вижу, что этот способ действительно полезен в определенных сценариях и фреймворках.
Вы можете найти его реализацию в версии 6.0.1 программы Why Did You Render.
Таким образом, мы полагаемся на разрешение модуля для использования React 16 (или любого другого набора библиотек). Мы запускаем тесты из папки со своим node_modules
, где установлен React 16.
Итак, прежде всего мы открываем новую папку, которая будет служить отправной точкой для второго набора тестов. F.E test-react-16
.
Затем мы создаем package.json
в этой папке со всеми библиотеками, которые мы хотим там протестировать, вместо тех, которые установлены в корне package.json
:
мы гарантируем, что всякий раз, когда мы устанавливаем наши пакеты, пакеты из этой новой папки также будут установлены, используя сценарий npm prepare
, который запускается всякий раз, когда вы запускаете yarn
.
Вот как это выглядит:
"prepare": "cd test-react-16 && yarn",
А вот так выглядит беговая пряжа при таком подходе:
Затем мы создаем специальный jest.config.js
, который:
- Явно устанавливает rootDir шутки как настоящую корневую папку за пределами новой тестовой папки.
- Папка
node_modules
имеет приоритет над основнымnode_modules
при использовании параметра moduleDirectories.
Нам также нужно позаботиться о других проблемах, например, чтобы убедиться, что babel работает правильно, добавив файл babel.config.js
в новую папку, которая указывает на папку за ее пределами:
Последняя папка с собственным node_modules
выглядит так:
теперь нам просто нужно запустить тесты из новой папки:
"test:react-17": "jest --config=jest.config.js", "test:react-16": "cd test-react-16 && jest --config=jest.config.js", "test": "yarn test:react-17 && yarn test:react-16"
Вот и все!
И снова я бы придерживался первого пути.
Благодарю вас!