Лучшие практики Node.js - тестирование и качество

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

В этой статье мы рассмотрим тестирование и поддержание качества кода Node.js.

Как минимум написать тесты API (компонентов)

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

Создавать тесты для нашего приложения очень просто. Мы можем использовать тестовые фреймворки, такие как Jest, и библиотеки, такие как Superagent, для тестирования наших API.

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

Например, мы можем легко добавить тесты в приложение Express с помощью Jest и Supertest, запустив:

npm i jest supertest

Затем мы пишем следующее:

index.js :

const express = require('express');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));
app.get('/', (req, res, next) => {
  res.json({hello: 'hello'});
});
module.exports = app;

index.test.js :

const request = require('supertest');
const app = require('./index');
describe('hello test', () => {
  it('/ should return hello response', async () => {
    const res = await request(app)
      .get('/')
    expect(res.statusCode).toEqual(200)
    expect(res.body).toEqual({hello: 'hello'})    
  })
})

В файле кода мы добавили supertest в наш index.test.js тестовый файл. Затем мы тестируем наш маршрут, отправляя запрос к маршруту / и проверяя код и тело ответа.

Метод toEqual проверяет полное равенство, чтобы мы могли проверить любое значение.

Включите 3 части в каждое название теста

Каждое название теста должно состоять из 3 частей, чтобы люди, читающие тестовые примеры, знали, что тестируется. Название теста должно включать в себя то, что тестируется, какие сценарии и каков ожидаемый результат.

Структурные тесты по шаблону AAA

AAA расшифровывается как Arrange, Act и Assert. Первая часть теста должна настроить данные для наших тестов. Затем мы фактически запускаем код, а затем утверждаем, что возвращенный результат является ожидаемым.

С помощью таких тестов мы понимаем основной код, просто глядя на тесты.

Выявление проблем с кодом с помощью линтера

Мы должны использовать анализатор кода для проверки основных проблем с качеством нашего кода. Ошибки интервалов, форматирования и синтаксиса находятся в его области. Он также проверяет общие антипаттерны, чтобы убедиться, что в нашем коде их нет. Линтеры с надстройками Node также могут проверять наличие проблем с безопасностью в нашем коде.

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

Избегайте использования глобальных испытательных приспособлений и семян

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

Это уменьшает множество головных болей с помощью тестов. Они не должны зависеть от каких-либо внешних зависимостей.

Проверьте наличие уязвимых зависимостей

Мы можем использовать npm audit или snyk.io для проверки уязвимых зависимостей, чтобы обновлять эти пакеты как можно быстрее.

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

Пометка тестов

Пометка тестов позволяет нам легко их искать. Мы можем добавить теги к именам тестов, чтобы их было легко найти.

Проверить тестовое покрытие

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

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

Проверьте наличие устаревших пакетов

Мы можем проверить устаревшие пакеты с помощью npm outdated и npm-check-updates, чтобы обнаружить устаревшие пакеты. Мы также можем запустить его в нашем конвейере CI, чтобы предотвратить успешную сборку, если у нас есть устаревшие пакеты.

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

Заключение

Добавлять тесты легко с помощью приложений Node. Это позволяет нам без особых усилий проверять наличие регрессии. Когда мы разделяем наши тесты для тестирования небольших фрагментов кода, тогда добавление тестов требует небольших усилий. Это особенно просто с тестовыми фреймворками, такими как Jest, и тестовыми HTTP-клиентами, такими как Superagent.

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