Работа в 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. А теперь иди и напиши тесты!