Улучшите Dx и качество кода с помощью автоматизированных интеграционных тестов

Научитесь уменьшать количество дефектов в своем программном обеспечении с помощью этих NodeJs + Jest + Database + Docker + GitlabCI учебник

Введение

Опыт разработчика — относительно новый термин, описывающий опыт технической команды при работе над продуктом. Хороший DX повысит продуктивность и счастье вашей команды. Плохой DX, скорее всего, приведет к текучести кадров в вашей команде.

Вот как вы можете быстро улучшить DX своей команды и одновременно улучшить качество своего программного обеспечения: автоматические интеграционные тесты.

В этой статье я буду использовать NodeJS + Jest в качестве среды тестирования. Тесты будут интегрированы с базой данных MongoDB и будут автоматически запускаться в GitlabCI.

Мы также будем запускать тесты локально, автоматически запуская Docker-экземпляр MongoDB при запуске тестов.

В своей статье я использую MongoDB, но процесс такой же для любой другой базы данных (MySQL, PostgreSQL и т. д.).

Хорошо, давайте перейдем к коду! (Полный код можно найти здесь на GitLab)

Местное развитие

Nodejs + Jest + Докер

NodeJs

Во-первых, давайте настроим наш проект NodeJs с mongoose и babel, чтобы мы могли использовать синтаксис ES6.

mkdir jest-mongo-docker
cd jest-mongo-docker
yarn init
yarn add mongoose
yarn add -D @babel/core @babel/node @babel/preset-env

Следующий код — это .babelrc. Поместите это в корень вашего проекта:

Код

Для нашего примера у нас будет модель Hero.

Я добавил некоторые ограничения только для того, чтобы использовать проверку мангуста и написать неудачные тесты.

Давайте добавим код в a service с вызовами моделей мангуста.

Хорошо, теперь, когда у нас есть код домена, давайте настроим Jest и напишем несколько тестов!

Шутка

Давайте установим Jest как devDependencies с помощью следующей команды:

yarn add -D jest

Добавьте эту команду скрипта в свой файл package.json:

"test": "jest --config ./jest.config.js --detectOpenHandles"

Это говорит jest использовать файл конфигурации с именем jest.config.js, который находится в корне вашего проекта. Параметр --detectOpenHandles очень полезен, когда вы имеете дело с таймерами и асинхронным кодом в своих тестах, чтобы, как следует из его названия, обнаруживать, например, оставленные открытыми соединения или неразрешенные промисы.

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

Имена наших утилит довольно просты:

• dbConnect используется для инициализации соединения с базой данных. Как видите, с process.env.CI что-то не так. Если у вас есть собственный экземпляр MongoDB, просто поместите его URI в константу uri.
• dbDisconnect используется для уничтожения нашей базы данных и закрытия соединения.
• Поскольку мы хотим, чтобы все наши тесты были независимы друг от друга, мы используем данные от dbClear до deleteAll из наших коллекций.

А теперь собственно тесты:

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

Если вы указали в файле utils.js URL-адрес уже запущенного и работающего сервера MongoDB, оба теста уже должны стать зелеными.

Однако, если вы ничего не меняли, вы должны получить следующую ошибку:

Давайте исправим это в следующем разделе!

Докер + GitLabCI

Мы собираемся запустить экземпляр докера MongoDB в шутку, а также в GitlabCI.

Во-первых, добавьте эту конфигурацию jest в корень вашего проекта:

globalSetup и globalTeardown — это поля, используемые для указания путей к файлам для выполнения до и после того, как jest выполнит всю серию тестов.

globalSetup цели:

• Определите, выполняются ли тесты локально или в GitLab.
• Запустите экземпляр Docker MongoDB, если он находится в локальной
• Подождите, пока будет создано соединение с MongoDB.

Как видите, в начале файла есть константа environmentKeysToDelete. Это массив strings, который вы можете использовать для удаления ключей .env, чтобы убедиться, что вы не запускаете свои тесты в разных средах (разработка, подготовка, производство и т. д.).

globalTeardown цель довольно проста: после того, как jest завершит выполнение всех тестов, удалите экземпляр докера MongoDB, если мы выполняем тесты на локальном хосте.

Теперь, если вы запустите yarn test (без установки собственного URI монго), все должно стать зеленым!

Теперь, когда все настроено для локальной разработки, давайте обратимся к GitLab!
Создайте файл .gitlab-ci.yml в корне вашего проекта. Что происходит, так это то, что GitLab при каждом нажатии на ваши разные ветки GitLab запускает конвейеры на основе вашего скрипта. Вы можете запускать тесты, создавать свое приложение, развертывать его на разных облачных провайдерах и т. д.

Здесь мы сосредоточимся только на тестах.

stages — это имя массива, которое вы даете своим конвейерам.

automated-tests — это имя job, управляющее моим test stage.

Я говорю ему использовать образ докера node:16-alpine. Затем я говорю ему использовать службу mongo для этой работы. Обратите внимание, что псевдоним mongo-test совпадает с переменной MONGO_TEST_HOST.

Это связано с тем, что в наших сценариях установки tests мы используем эту переменную для подключения к нужному хосту, когда находимся в конвейере CI.

Если вы отправите этот файл, вы должны увидеть это в пайплайнах вашего проекта:

Поздравляем! Вы успешно настроили интеграционные тесты на локальном хосте и автоматизировали их в своем CI.

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

Спасибо, что прочитали, и следите за новостями!