В этом посте мы познакомимся с Mocha как с тестовым фреймворком вместе с should.js и supertest. Тестирование супертеста позволяет вам тестировать ваши утверждения HTTP и тестировать конечные точки API. Это то, что я узнал из одной из хороших книг под названием Основы Node.js.

Тесты обычно помещаются в корневую папку /test. Тесты полностью отделены от любого исходного кода. Хорошо написанные тесты с хорошим охватом могут служить ридми для его API, поскольку он четко описывает поведение всего приложения. Во многих фреймворках модульного тестирования Mocha использует утверждения, чтобы убедиться, что тест выполняется правильно. Если выдается ошибка и не обрабатывается, то тест считается неудачным. Что делают библиотеки утверждений, так это выдают ошибки при передаче неожиданного значения. Mocha предоставляет множество способов создания тестов, которые называются интерфейсами, а значение по умолчанию - BDD.

Чтобы гарантировать установку мокко, нам необходимо установить его глобально. Запустите npm install -g mocha

Это пример базовых тестов в Mocha.

И мы поместим все тестовые файлы в папку src/test/name-of-file.js, мы протестируем основные операции CRUD, создав новый объект todo, извлечем, отредактируем и удалим объект todo. Это пример теста для создания нового todo, который показан следующим образом:

Мы создаем новый запрос POST для нового актера в базе данных, а затем отправляем запрос с функцией .send(). Подобные тесты присутствуют для запросов GET и DELETE, как показано в следующем фрагменте кода:

Чтобы проверить запрос PUT, мы отредактируем task и is_done нашего первого объекта todo следующим образом:

Чтобы немного объяснить, первая часть теста изменяет объект todo, а затем отправляет запрос PUT для /todos/1 (: id), а затем сохраняет новую информацию в базе данных. Затем во второй части теста проверяется, была ли изменена запись в базе данных для объекта todo. Объект todo проверяется на соответствие их ожидаемым значениям с помощью .should.eql().

Помимо выполнения действий CRUD над объектом todo, мы также можем выполнять эти действия с задачами, которые мы добавляем к каждому из них. И этот фрагмент кода показывает тест для добавления новой задачи к нашей первой задаче с идентификатором 1.

Этот тест кода создает новый объект плана и отправляет запрос POST для добавления плана в виде массива к объекту todo. Вторая часть отправляет запрос GET для получения задачи с идентификатором, который должен включать массив нового плана.

Аналогичным образом мы можем удалить записи плана следующим образом:

В этом коде есть тесты 1-й части, которые отправляют запрос DELETE с указанием идентификатора задачи, а идентификатор плана удаляет эту запись плана. Мы убеждаемся, что запись больше не существует, отправив запрос GET для просмотра объектов todo, планы которых там не должны быть перечислены.

Помимо проверки работы основных операций CRUD, мы также тестируем проверку нашей схемы. Вот как это сделать. Мы позаботимся о том, чтобы 2 задачи с одинаковым идентификатором не существовали, поскольку идентификатор определен как уникальный.

Мы должны ожидать кода состояния 400 для неверного запроса, если мы попытаемся создать объект todo, который уже существует в базе данных.

Бонус:

Чай

Помимо множества фреймворков тестирования, существует также множество фреймворков для утверждений, одна из которых - Chai. Вместо того, чтобы просто использовать встроенное утверждение, предоставляемое Node.js, мы можем использовать такой модуль, как Chai, для расширения возможностей. Чат имеет 3 набора интерфейсов: следует, ожидать и утверждать. Я приведу один пример, который ожидает обложки. Некоторые примеры использования Chai:

Методы вставки

Дело в том, что когда вы пишете свои тесты, вы хотите тестировать только единицы кода. Это может быть метод, предоставить ему ввод и ожидать какой-либо результат. Затем вы должны подумать о своем приложении, в котором оно не может общаться с внешним миром, например, как общаться с базой данных или делать какие-либо внешние запросы. И вы, вероятно, захотите имитировать методы, о которых вы знаете, что это происходит выполнить. Отличный модуль для этого - Sinon.js, он позволяет создавать заглушки и шпионов, чтобы гарантировать, что правильные данные возвращаются из других методов, и гарантировать, что они были вызваны в первую очередь. Sinon.js предоставляет множество помощников. , бывший. шпион. Шпион используется в основном для того, чтобы просто обернуть функцию, чтобы увидеть, что ее ввод и вывод были. После того, как шпион был применен к функции во внешнем мире, он ведет себя так же

Мы можем использовать шпион, чтобы проверить, вызывается ли функция

assert(spy.callled)

или какие аргументы были переданы для каждого вызова:

assert.equal(spy.args[0][0],1)

Теперь это реальный пример сценария. Допустим, у нас есть эти методы

Поскольку getUser () выдаст ошибку, если не сможет ее найти. И мы хотим проверить, что когда пользователь найден, он возвращает его имя. Заглушим метод:

Вот несколько основных тестов с Express.js при реализации операций CRUD с конечными точками API. Надеюсь, что это поможет! И счастливого тестирования: D