Несколько дней назад я написал историю о том, как я структурирую свои REST API для Node.js. Однако я не охватил там никаких тестовых сценариев. Так что пришло время наверстать упущенное.

Мы собираемся написать модульный тест для одного компонента API на основе структуры проекта из моей другой истории. Цель состоит в том, чтобы протестировать компонент путем имитации базы данных и отправки HTTP-запроса по ее маршрутам.



Для написания тестов я использую следующие узловые модули:

  • Мокко
  • Чай
  • Супертест

Структура проекта

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

nodejs-api-structure
└───src
   │
   └───config
   │
   └───api
   │   │
   │   └───components
   │   │   │
   │   │   └───user
   │   │       │   controller.ts
   │   │       │   model.ts
   │   │       │   routes.ts
   │   │       │   service.ts
   │   │       │   user.spec.ts
   │   │
   │   └───middleware
   │   │
   │   │   routes.ts
   │   │   server.ts
   │
   └───test
   │   │   factory.ts
   │
   │   index.ts

Мы сосредоточимся на следующих файлах:

  • factory.ts
  • user.spec.ts

Завод испытаний - factory.ts

Этот файл представляет собой своего рода установочный файл для каждого отдельного модульного теста. Он заботится о подключении к базе данных и запускает сервер Express.js.

Мы используем «sqljs» в качестве типа базы данных, поэтому нет необходимости предоставлять настоящую базу данных, такую ​​как MySQL или любую другую.

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

Компонентный тест - user.spec.ts

Этот файл охватывает модульный тест для компонента API. Там мы используем разные методы HTTP-запроса, такие как POST, PUT, GET и DELETE для тестирования API компонента. конечные точки.

Прежде всего, мы создаем новый экземпляр класса TestFactory и модели User. Методы mockTestUser возвращают экземпляр User, включая некоторые фиктивные данные. Кроме того, мы создаем еще один экземпляр testUserModified с некоторыми измененными свойствами, который будет использоваться для тестирования конечных точек PUT.

Теперь мы определяем методы before и after Mocha. before выполняется до начала теста, а after выполняется после его завершения.

Внутри них мы вызываем фабричные методы init и close, которые устанавливают новое соединение с базой данных и экспресс-сервер до начала теста и отключаются от него, когда он закончился.

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

Для выполнения HTTP-запросов к серверу я использую Supertest и Chai для проверки ответов сервера.

Вот полный код одного компонента:

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



В настоящее время я работаю над дополнительным проектом, где вы можете увидеть в действии сценарии тестирования, подобные этому. Взгляните, например, на модель User или Task.