Часть №4 - Настройка тестовых наборов для вашего сервера
Что вы будете делать в этой части
В этой части проекта вы интегрируете службу регистратора в свое приложение узла, чтобы лучше отслеживать данные, проходящие через ваш сервер, и немного упростить процесс отладки.
В основном вас проинструктируют о том, как настроить тестовую среду для вашего приложения, наборы тестов для вашего приложения и протестировать маршрут API в различных случаях с помощью лучших фреймворков для тестирования Node.JS.
Таблица содержания - Часть №4
- Интеграция службы Logger
- Создание наборов тестов
◢ Конфигурация тестовой среды
◢ Структура набора тестов
◢ Начать тестирование
◢ Тестирование маршрутов API
Если вы еще не читали предыдущие статьи этой серии, вот ссылки:
Часть № 1 - Создание клиентской части IDE с помощью Angular и Bootstrap
» Часть № 2 - Создание вашей на стороне сервера с Node.JS, Express и Typescript
Часть № 3 - Создание маршрутов вашего API
Интеграция службы Logger
Использование службы ведения журнала вместо простого распространения console.log по вашему коду - гораздо лучшая практика, только некоторые из ее преимуществ:
- Это дает вам контроль над визуальным представлением регистрируемого контента (ограничение длины, формат, стиль / цвет и т. Д.).
- Вы также можете управлять потоком, чтобы записанный контент был направлен (поток уровня журнала, файл журнала и т. Д.).
- Вы можете легко указать условия или среду для отключения звука потока регистратора.
- Название, стиль, поведение и поток уровня журнала полностью находятся под вашим контролем.
Есть много отличных библиотек журналов; Morgan, Winston, Bunyan, Loglevel и многие другие, которые вы можете найти в NPM с поисковым словом« logger ».
Без каких-либо вопросов, вы всегда должны предпочесть использовать библиотеку, которая был протестирован и доказал свою работоспособность миллионами, над разработкой самостоятельно с нуля (если только это не то, о чем ваш проект).
Из-за моих собственных визуальных предпочтений и некоторых технических требований я написал собственный (относительно простой) сервис регистратора и использовал его в большинстве своих проектов.
Итак, прежде чем я смогу предложить вам воспользоваться моей службой регистрации, пожалуйста, взгляните 👇
Как войти в систему с помощью Morgan:
Как войти в Winston:
Как войти с помощью Bunyan:
My Simple Logger Service:
Вот облегченная версия моего Simple Logger, когда я говорю облегченная версия, я имею в виду, что это небольшая часть исходного кода проекта Simple Logger, часть, которая удовлетворяет требованиям этих проектов, со значениями конфигурации по умолчанию, разработанными специально для случаев использования этого проекта (чтобы не утомлять вас).
Исходный код здесь.
Для полного исходного кода Simple Logger (с несколькими потоками журналов, конфигурацией ExpressJS, фильтрацией журналов и другие функции) проверьте мой Git.
Если вы решили использовать его (облегченная версия), то есть только 4 файла кода, создайте их с одинаковым содержанием по сути, поместите их все в одну папку (util/logger подойдет) и установите пакет colors. :
npm i colors --save
В своем коде импортируйте sample-logger класс и создайте его экземпляр, теперь везде, где вы раньше использовали console.log, теперь используйте один из методов уровня журнала в sample-logger классе.
console.log('hello'); ==>
loggel.INFO({msg: 'hello'});
console.log('res body', JSON.stringify(res.body)); ==>
loggel.INFO({msg: 'res body', params: {body: res.body}});
Создание наборов тестов
Большая часть ответственности разработчика заключается в том, чтобы тестировать создание (по крайней мере, серьезных) ошибок и нежелательного поведения.
Это правда, что тестирование - это наша собственная область, но даже если вы не тестировщик, вы должны хотя бы ознакомиться с ним, не всегда будет кто-то другой, чтобы протестировать ваш код, плюс, на многих начинающие компании с небольшими командами, тестирование вашего или чужого кода будет выполнено вами или не будет выполнено вовсе.
Конфигурация тестовой среды
Mocha и Chai - отличные библиотеки для тестирования, Mocha - это основной фреймворк, с которым вы будете работать, а Chai - это библиотека утверждений.
Установите их (как dev-зависимости);
npm install mocha @types/mocha chai @types/chai --save-dev
добавьте к свойству scripts в вашем package.json новый test скрипт:
"test": "SET NODE_ENV=test&& mocha --require ts-node/register server/tests/**/*.test.ts"
В этом скрипте вы устанавливаете для NODE_ENV значение test, а затем указываете mocha выполнить все файлы в папке server/tests с именем, которое соответствует *.test.ts регулярному выражению (другой аргумент для компиляции наборов тестов в js).
Из этого вы можете понять, что все ваши наборы тестов будут помещены в папку server/tests с любым именем, заканчивающимся на «.test.ts».
Структура набора тестов
Базовая реализация теста будет помещена в метод describe со строкой, описывающей то, что вы тестируете в нем, и обратным вызовом с реализацией тестирования, которое имеет место.
Блок describe() (обратный вызов, который вы ему предоставляете) содержит один или несколько блоков it() и аналогично блоку describe(), вы предоставляете it() методу строку, описывающую ожидаемый результат теста (обычно начинающийся со слова «следует»), и обратный вызов с действием тестирования.
Начать тестирование
Для начала, чтобы разобраться в этом, давайте сначала создадим набор тестов для LanguagesManager класса.
Создайте в папке server/tests новый файл с именем languages-manager.test.ts со следующим:
В классе LanguagesManager всего три метода, все относительно простые, каждый метод тестируется на отдельном it() методе.
Строковые параметры для методов describe() и it(), хорошо объясняющие, что происходит в каждом тесте.
В простых тестах, обычно с синхронными действиями, последовательность действий довольно стандартна: сначала вы упорядочиваете параметры для выполнения теста, затем выполняется действие часть, в которой вы выполняете действие тестирования, а последняя - это подтверждение результата тестирования с тем, что вы ожидаете получить.
Боковое примечание - для того, чтобы результат тестирования отображался на консоли так, как ожидалось, вы должны заглушить все остальные корки на консоли. С предоставляемым мной сервисом регистратора, который обрабатывается автоматически, эта конфигурация должна быть простой в настройке на большинстве служб регистратора.
Тестирование маршрутов API
Для тестирования маршрутов API вам потребуется другая зависимость, Supertest (Superagent) - библиотека утверждений HTTP, идеально интегрированная с экспресс-фреймворком.
Установите пакет supertest (как dev-dependency):
npm i supertest @types/supertest –-save-dev
Давайте рассмотрим пример использования Supertest в среде, похожей на вашу;
import * as request from 'supertest';
import { expect } from 'chai';
import { app } from '../server';
describe('GET /user', function() {
// 'done' parameter is a callback used on asynchronous testing.
it('respond with json', function(done) {
// requesting the app instance
request(app)
// calling the GET: /user API route
.get('/user')
// setting request header
.set('Accept', 'application/json')
// assert 'Content-Type' header
.expect('Content-Type', /json/)
// assert status code is 200
.expect(200)
// end() Perform the request and invoke the callback
.end((err, res) => {
// here you can use Chai assertion method
expect(res.body).to.have.property('users');
// calling done to alert Mocha the test has ended
// passing any error object in case you got one
done(err);
});
});
});
Асинхронные тесты с Mocha - добавляя обратный вызов (обычно называемый done) к it(), Mocha будет знать, что ему следует дождаться вызова этой функции для завершения теста. (из документов Mocha)
Чтобы выполнить эти тесты API, вы должны сначала экспортировать свой app экземпляр, чтобы вызовы API могли быть вызваны супертестом из наборов тестов.
Изучив пример набора тестов, используя все вместе Mocha, Chai и Supertest, мы можем продолжить создание наборов тестов для ваших реальных маршрутов API.
Итак, сначала добавьте небольшое изменение в server.ts, в конце файла экспортируйте свой app экземпляр;
...
...
app.listen(process.env.PORT || PORT, () => {
console.log(`server running on port ${process.env.PORT || PORT}`);
})
export { app } // export for testing
Теперь создайте новый файл в папке server/tests с именем app-routes.test.ts и добавьте к нему свой первый набор тестов GET: /langs маршрута API,
попробуйте написать его самостоятельно, на основе приведенного выше примера.
В комментариях объясняется каждая строка, но, вкратце, вы утверждаете стандартные параметры запроса, а затем на end() вы утверждаете, что тело ответа содержит свойство langs с объектом languageTable в качестве его значения.
Следующий маршрут для создания набора тестов - POST: /run, он будет очень похожим, но немного другим.
Предыдущий маршрут был методом GET, он не получил никаких конкретных параметров для проверки, поэтому его поведение было чтобы оставаться неизменным для любых входящих запросов, вы протестировали только один сценарий.
В этом наборе тестов маршрута (POST: /run) вы будете тестировать несколько сценариев, есть параметры, прикрепленные к телу входящего запроса, и запрос реагирует по-разному, в зависимости от статуса проверки этих параметров.
Здесь вы тестируете четыре сценария, первый - лучший случай, когда все параметры указаны, второй - случай, когда свойство lang body содержит неподдерживаемый язык, все остальные - варианты второго случая.
Вы можете легко придумать больше сценариев для тестирования, если считаете, что необходимо больше, попробуйте, и с этим самостоятельно 🌴.
Давайте рассмотрим
- Вы интегрировали в свое приложение службу регистрации.
- Вы настраиваете тестовую среду - Mocha & Chai и создаете набор тестов для служебной службы в своем приложении.
- Вы установили пакет Supertest, рассмотрели пример построения набора тестов с использованием Mocha & Supertest.
- Наконец, вы создаете наборы тестов для своих маршрутов API.
Вы закончили создание наборов тестов для маршрутов вашего API.
Следующая часть - подключение клиента к серверу и демонстрация функций редактора кода, которые будут использоваться в вашем приложении.
