Работа в React Native была потрясающим опытом. Исходя из React, рабочий процесс был почти беспроблемным. Однако остался один вопрос: Как, черт возьми, я собираюсь это проверить?

В частности, как лучше всего провести модульное тестирование логики моего компонента? Тестирование JavaScript, который компилируется в собственный код с помощью утилит тестирования на основе DOM, не работает. Я могу выполнять функциональное тестирование с помощью Appium или встроенных тестов Xcode UI, но мне нужен был способ модульного тестирования моих компонентов.

Моки спешат на помощь

Оказывается, вы можете изолированно тестировать логику компонентов React Native с помощью традиционных тестовых библиотек JS, заставляя React Native возвращать обычные компоненты React вместо собственных.

Ниже приведена моя прокладка для компонентов и методов React Native, которая позволила мне визуализировать их в моей тестовой среде:

Mocking React Native с помощью Mocha

Сначала я попробовал поиздеваться над всем с помощью Jest, в основном потому, что это было официально рекомендовано. Мне удалось доказать эту концепцию, но у меня было несколько недостатков:

  • Jest неоправданно медленный, по крайней мере, по сравнению с альтернативами
  • Обычно мы используем Karma / Mocha / Chai в проектах Web React на Formidable, поэтому было бы неплохо продолжить это соглашение.

Попрощавшись с Шестом, я должен был понять, как это будет работать с Mocha. Я не мог использовать настройку Karma / Webpack, как в Интернете, потому что React Native использует собственный упаковщик, поэтому использование Webpack было бы избыточностью. Это означает, что мне пришлось написать компилятор для а) преобразования кода Babel и б) разрешения модуля React Native с помощью фиктивной версии.

Mocha принимает аргумент - compiler, который я использовал для создания пользовательского загрузчика модуля. Я создал один ниже, который будет преобразовывать файлы .js и вставлять имитированные методы React Native в требования react-native:

Теперь каждый раз, когда модулю в тестовом файле требуется react-native, вместо этого он получит прокладку.

Собираем все вместе

Теперь у меня есть макет и собственный компилятор, и я хочу увидеть его в действии. Моей первой задачей было установить зависимости, необходимые для запуска тестов. Чтобы упростить задачу, я просто запустил:

npm i --save-dev mocha chai sinon react react-dom react-addons-test-utils enzyme

Кратко рассмотрим роль каждого инструмента в архитектуре тестирования:

  • Mocha: фреймворк для тестирования Javascript.
  • Чай: Библиотека утверждений
  • Синон: заглушки, макеты и шпионы
  • Enzyme: утилита для тестирования реакции.
  • React Test Utils: помощники по тестированию React
  • React & ReactDOM: используется для имитации React Native для тестирования.

Затем мне пришлось создать файл mocha.opts, который используется для предоставления параметров Mocha. В каталоге / test я создал файл mocha.opts и добавил следующее:

Затем я создал compile.js и setup.js в нашем тестовом каталоге. Код компилятора, который я написал ранее, помещался в compile.js, и я поместил следующий код в setup.js, чтобы я мог предоставить chai.expect глобально, в основном по эргономике:

Затем я создал response-native.js в новом каталоге mocks в / test в /test/mocks/react-native.js и поместите туда макет кода React Native, полученный ранее.

Последний фрагмент головоломки - указать мой тестовый сценарий npm на Mocha с указанными параметрами. Я открыл package.json и изменил тест в скриптах на:

"test": "mocha --opts test/mocha.opts src/**/__specs__/*.spec.js"

Помимо указания на определенные параметры, я также установил цель для тестов, использующих соглашение * .spec.js, расположенных в папках с именем __specs__

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

Пришло время проверить!

Получение моего теста на

Скажем, у нас есть простой компонент React Native, который мы хотим протестировать, чтобы убедиться, что он отображает дочерние узлы в ответ на опору items:

Мы хотим начать с создания каталога __specs__ в src / components /. Внутри этого каталога мы создаем our-component.spec.js в качестве нашей тестовой спецификации для указанного выше компонента.

Для этого теста мы будем использовать неглубокий рендеринг, который рендерит компоненты на один уровень глубже и позволяет нам утверждать, что это виртуальная структура DOM. Мы также будем использовать библиотеку энзимов от замечательных ребят из Airbnb, которая является замечательной утилитой для работы с мелкими рендерами.

Начнем с импорта React, фермента и нашего компонента и создания описательной группы:

Теперь, когда у нас есть набор этапов, давайте создадим некоторые фиктивные данные пропуска, выполним поверхностный рендеринг нашего компонента и воспользуемся методом фермента findWhere, чтобы проверить, все ли в рабочем состоянии:

Теперь все, что осталось сделать, это запустить npm test и позволить волшебству случиться. Мы проводим модульное тестирование компонентов React Native!

Заворачивать

Я нахожу этот подход достаточно гибким до сих пор, и я чувствую себя намного лучше в отношении надежности моего кода React Native. Возможно, вы заметили, что в макете React Native выше я только смоделировал подмножество функциональности. Использование этого подхода может потребовать имитации дополнительных компонентов и методов в зависимости от того, что вы используете в своем приложении. Я также рекомендую изучить все возможности фермента, так как он имеет элегантный API для обхода и запросов к объектам ShallowRender. А теперь иди и напиши тесты!