Несколько дней назад я написал историю о том, как я структурирую свои 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
.