В своем самом первом проекте на Хакатоне я решил попробовать свои силы в мобильной разработке, а именно в мобильной карточной игре, с любовью названной «Card Creatures». Безумно изобретательные соглашения об именах - не моя сильная сторона. Я работаю над этим.

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

Для большого открытия я решил реализовать простую карточную RPG (Role Playing Game). Каждая собираемая карта имеет очки здоровья и магии, что позволяет ей получать и наносить урон. Игрок также может использовать вспомогательные карты, которые могут увеличить HP и MP целевого Существа.

Это мой первый набег на мобильную разработку, и я надеюсь однажды с любовью оглянуться назад на 48 часов, потраченных на борьбу с веб-шаблоном (который впоследствии был отброшен на шаблон, который я создал самостоятельно) и безумные усилия по интеграции React-Native с Redux, Express и Sequelize. Но теперь, когда я приближаюсь к созданию работающего приложения, в духе перехода по одному мосту за раз, пришло время написать тесты.

Я буду использовать тестовый фреймворк Javascript Mocha и библиотеку утверждений Chai, чтобы убедиться, что все мои милые, приятные Card Creatures работают с максимальной отдачей. и плагин ChaiAsPromised и Supertest, чтобы все мои асинхронные данные, получаемые из серверной части, были аккуратными и аккуратными. И последнее, но не менее важное: Jest стал моим предпочтением при тестировании компонентов React-Native. Мой проект основан на таких основах, как React-Native, Redux, Express и Sequelize, поэтому, чтобы укрепить эти основы, я напишу несколько тестов для каждого сегмента!

Если ваш стек выглядит как мой собственный, не стесняйтесь следовать этому руководству!

Настройка

Нам понадобится сохранить Mocha и Chai в нашем package.json devDependencies. Итак, предполагая, что вы используете узел, перейдите в свой рабочий каталог и введите следующее в свой терминал.

npm install --save-dev mocha chai chai-as-promised

Что касается организации файлов, вам решать, где вы будете хранить свои тесты. Я предпочитаю хранить тесты рядом с их целевыми файлами, поэтому я просто создал файл «tests.spec.js» в каждом подкаталоге, который будет целью этих тестов. Что-то вроде…

…
сервер
| _ api
| ___ cards.js
| ___ враги.js
| ___ index.js
| ___ saveGame.js < br /> | ___ tests.spec.js
…

(В полевых условиях лучше быть слишком конкретным при именовании файлов, чем недостаточно конкретным - это означает, что «tests.spec.js» не поможет. В общем, я предлагаю отметить, ЧТО вы тестируем. Например, apiCardRoutes.spec.js или вражескийComponent.spec.js были бы более разумным выбором. Делайте, как я говорю, а не как я!)

В файле package.json создайте сценарий, который будет запускать ваши тесты. Я ищу радости в мелочах, поэтому я назвал сценарий «существо-особенность-квест-тест».

Вы заметите, что «test: server» указывает на первый раунд тестов, которые я написал - тесты для моих моделей!

Тестирование модели сиквелизации

Вначале были простые, скромные определения модели Sequelize - без них мои существа не существовали бы! Поэтому особенно важно их тщательно протестировать.

В моей папке server / db я написал файл с именем «tests.spec.js», который требуется в необходимых компонентах Chai вместе с самими моделями:

Затем я получил право работать над тестированием своей модели Card. Наиболее важные тесты, которые нужно было написать, касались правильной аутентификации модели. Если вытащить карту существа, у которого 0 очков здоровья, я бы действительно выжил.

Соответственно, я хотел, чтобы мои тесты касались следующего:

  1. У каждой карты должно быть имя, в частности строковое значение.
  2. Каждому из них должны быть предоставлены очки жизни и магии (HP / MP) в виде целого числа.
  3. Карту следует проверять только в том случае, если поле imageUrl фактически является URL-адресом. (Я предоставил значение по умолчанию с общим изображением, которое вы можете увидеть на скриншоте выше).

Мои итоговые тесты вместе с некоторыми пояснительными комментариями:

Запуск npm run test:server (после создания нескольких дополнительных тестов для моих моделей SaveGame и Enemies) дает прекрасный набор зеленых галочек:

Экспресс-тестирование маршрута

Я хранил все свои карты, их статистику, сохраненные игры и врагов на сервере. Чтобы получить эти данные, мне нужно было написать несколько простых маршрутов Express.

Для тестирования этих маршрутов я воспользовался помощью Supertest, который позволяет мне безболезненно делать HTTP-запросы к бэкенду. Я просто потребовал, чтобы он был в верхней части моего существующего файла tests.spec.js как const request = require(“supertest”);.

Не забудьте добавить супертест в свои devDependencies! npm install --save-dev supertest

Что касается моих экспресс-маршрутов, я хотел подтвердить следующее:

  1. Переход к /api/cards, /api/enemies и /api/saves вернет все соответствующие наборы данных с сервера.
  2. Я мог указать конкретную карту / врага / сохранение, указав идентификатор (например, /api/cards/2).
  3. Если запрос привел к несуществующему фрагменту данных, будет возвращено 404.

А вот и мои тесты на экспресс-маршрутах:

React-Native тестирование с Jest

Наконец, мы подошли к тестированию глянцевого фасада моего приложения - возможно, еще не суперглянцевого. В конце концов, я нахожусь на стадии pre-pre- pre -alpha.

Состояние моих карточных битв контролируется в магазине Redux. В том небольшом масштабе, в котором сейчас находится мое приложение, относительно просто отслеживать, сколько здоровья у врага может быть в любой момент или сколько карт у игрока может быть в их распоряжении. Всю эту информацию можно аккуратно объединить и извлечь, отправив ряд действий моим Enemy и Cards Reducers. Естественно, для правильного хода игры рекомендуется поддерживать их в рабочем состоянии.

К сожалению, я легко могу впасть в опасное самоуспокоение, когда дело касается тестирования моих компонентов React - я их вижу! Они делают это! Оно работает! Однако, пытаясь выработать хорошие привычки в самом начале моей карьеры инженера-программиста, давайте проверим и этих плохих парней!

Моим первоначальным побуждением было продолжать использовать Mocha и Chai для тестирования компонентов. Однако сообщество ясно дало понять, что это может доставить больше хлопот, чем пользы. Для этого мне потребуется имитировать любые нативные компоненты, которые необходимо протестировать, поскольку Mocha может запускать тесты только в браузере или Node.js, а для его работы требуется расширение для работы во фреймворке React-Native (JavaScriptCore).

Поэтому вместо этого я решил последовать рекомендации Facebook использовать Jest. На их веб-сайте есть удобное небольшое руководство для быстрого начала тестирования ваших компонентов React-Native, которое я использовал, чтобы начать этот сегмент моего тестирования.

Самая большая разница между средой тестирования Jest и другими, которые я использовал, заключается в том, что в ней используется функция моментальных снимков. Когда вы запускаете свой Jest-тест в первый раз, он делает снимок вашего пользовательского интерфейса в виде простого текстового файла (который был предварительно настроен для удобства чтения человеком). Ваши тесты не пройдут, если в какой-то момент ваш Компонент не будет выглядеть как этот снимок. Это позволяет вам вносить целенаправленные корректировки в компонент или отлаживать любые непреднамеренные изменения. Самым большим преимуществом здесь является то, что ваше приложение не нужно перестраивать каждый раз, когда вы хотите его протестировать! Я считаю этот метод тестирования действительно крутым и эффективным - вы можете узнать об этом вместе со мной, прочитав документацию.

На этих ранних этапах разработки я хотел бы, чтобы мои компоненты:

  1. Покажите список всех карточек в библиотеке пользователей (или уведомите их, если у них еще нет карточек).
  2. Отобразите соответствующие данные в виде подробной карты, включая соответствующее изображение.

По общему признанию, эта часть моего письменного руководства заняла больше всего времени, чтобы конкретизировать и изложить на бумаге. Я столкнулся с рядом ошибок, связанных с babel, из-за которых мой код не смог проанализировать, чтобы тесты Jest работали. Большую часть времени, потраченного на эту статью, я обязан хорошим специалистам из Stack Overflow!

Я начал с установки и сохранения следующих файлов в свой devDeps.

npm install --save-dev jest react-test-renderer

После этого мне пришлось проделать некоторые манипуляции с моими package.json и babel.config.js, чтобы Jest правильно запустил мои тесты. У меня сработали следующие конфигурации. Не забудьте также установить модули @babel/… из конфигурационного файла Babel в свои зависимости Dev!

Наконец, я смог выполнить набор простых тестов для базовой функциональности моих компонентов React-Native!

Теперь у меня есть небольшой набор тестов для моего любимого проекта Хакатона! Естественно, в этих тестах не рассматриваются сложные функции, но они, безусловно, только начало! Я с нетерпением жду, когда модульное тестирование React-Native начнет набирать обороты - прямо сейчас существует реальная нехватка документированного опыта разработчиков, окружающего его. Хотя, несмотря на дополнительные часы, потраченные на поиск фреймворка для тестирования для устранения причуд React-Native, несколько советов, приемов и привычек того стоили!

Если у вас был лучший опыт тестирования компонентов React-Native, чем у меня, я был бы рад услышать от вас в комментариях. Спасибо, что нашли время, чтобы прочитать, и я надеюсь, что вы найдете небольшой кусочек или два, которые помогут вам в вашем путешествии!