Мне нужен инструмент для правильной обработки тестирования после развертывания

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

(Эта статья была первоначально опубликована на моей странице dev.to)

Я наткнулся на инструмент newman cli от добрых людей с getpostman.com. Это CLI, инструмент с открытым исходным кодом, который запускает тесты, которые вы сохранили в своих коллекциях Postman, и выдает типичный вывод состояния ошибки/консоли, который вы ожидаете от любого современного инструмента тестирования, что означает, что вы можете интегрировать его в свой рабочий процесс CI/CD.

Для тех, кто не использовал Postman, это потрясающий инструмент для выполнения запросов к службам, хранения коллекций подключений и тому подобного, и если вы занимаетесь практически любой веб-разработкой, вам это нужно. Если вы слишком старомодны и любите использовать cURL для всего? Хорошо, он будет импортировать и экспортировать команды cURL для вас. Иди проверь.

https://www.getpostman.com/

Единственная проблема для меня — я так не пользуюсь Postman. На самом деле я не храню коллекции вещей, я просто использую их для тестирования или быстрой отладки. У нас есть хорошая коллекция интеграционных тестов, построенных вокруг наших спецификаций OpenAPI, на которую мы полагаемся, поэтому мне не пришлось делать то, что сделали другие, и создавать большую коллекцию конечных точек API.

Хитрость здесь заключается в том, чтобы свести дублирование к минимуму.

Начало работы: нам понадобится API для тестирования:

Я сохранил все для этого проекта, вы можете посмотреть все файлы на GitHub

// src/index.js
const express = require('express')
const bodyParser = require('body-parser')
const addRequestId = require('express-request-id')
const app = express();
app.use(addRequestId())
app.use(bodyParser.json())
app.get('/', (req, res) => {
   res.json({message: 'hello world', requestId: req.id});
})
app.get('/foo', ({ id, query }, res, next) => {
    const { bar } = query
    res.json( { bar: `${bar}`, requestId: id })
})
app.post('/foo', ({ id, body }, res, next) => {
    const { bar } = body
    if (typeof bar === 'undefined' ) { 
        return res
        .status(400)
        .json({ error: 'missing `bar`', requestId: id})
    }
    res.json( { bar: `${bar}`, requestId: id } )
})
const server = app.listen(8081, function () {
   const port = server.address().port
   console.log("Example app listening to port %s", port)
})

Итак, у нас есть три конечных точки для использования: / и /foo как GET, и /foo как POST. В конечной точке POST /foo есть небольшая проверка. Я добавил express-request-id и добавил его к ответам, чтобы мы могли убедиться, что они уникальны.

Начало коллекции

Я изучаю это, когда веду блог здесь, так что простите за отступление! Я зашел в почтальон и создал новую коллекцию под названием postman-newman-testing.

Хорошее начало, создана пустая коллекция

Я прошел, создал и сохранил запрос для каждой из трех конечных точек, добавив небольшое описание для каждой:

В коллекцию добавлено три запроса. Если у вас возникли проблемы с этим, я рекомендую очень полезную документацию в [Учебном центре Postman](https://learning.getpostman.com/)

Добавление тестов:

Помните, что цель здесь — создать что-то, что может помочь нам запустить некоторые тесты после развертывания, поэтому мы собираемся определить несколько простых тестов в коллекции для каждой из конечных точек. Я хочу убедиться:

  • Я получаю requestId за каждый ответ
  • Я получаю ответ 200 для каждого
  • Я могу вызвать ответ 500, когда ожидаю, что будет ошибка
  • Ожидаемые значения возвращаются для конечных точек POST /foo и GET /foo.

Как и следовало ожидать, вся документация по тестовым сценариям находится в Postman Learning Center, и, к счастью, она будет знакома всем, кто раньше работал с тестами и JS.

Итак, после небольшого взлома, я обнаружил кое-что интересное; когда вы делаете тесты, они выполняются каждый раз, когда вы выполняете этот запрос, поэтому, если вы используете Postman для разработки, вы не можете «забыть» запустить тесты.

Каждый раз выполняются четыре теста, поэтому мы проверяем код ответа, форму ответа, возвращаемый тип JSON и скорость, которую мы ожидаем

Вариации

Я хочу протестировать два разных вывода из конечной точки, успех и неудачу, но я не думаю, что мне нужно сохранять два разных запроса для этого, так как же мы собираемся тестировать нашу конечную точку POST /foo? Я собираюсь вернуться к этому в какой-то момент, как только я пойму больше.

Автоматизируйте все дела

У меня есть моя коллекция, настроенная со всеми тестами счастливого пути, и если открыть Collection Runner и запустить мою коллекцию (..), то я получаю красивую доску зеленых квадратов, говорящих мне, что мой API находится в очень базовый уровень, делая то, что я ожидаю от него.

Все 5 на 5

Давайте поработаем newman.

Я экспортировал коллекцию из Postman и сохранил ее под docs/postman-collection.json в корне проекта, установил newman ($ npm install --save-dev newman) и выполнил команду для запуска тестов:

Там есть все виды отличного вывода!

Так что это удивительно, я сделал несколько простых тестов API, но это не принесет мне никакой пользы по той простой причине, что в моей коллекции все мои URL-адреса установлены на http://localhost:8081, поэтому мне нужно решить, как это изменить.

После небольшого нажатия и поиска в Google мы можем это сделать. Postman поддерживает среды — вы можете увидеть их в правом верхнем углу главного окна. Я создал пару («разработка» и «постановка») и создал в них значение с именем host с http://localhost:8081 для development и https://api.mydomain.com:3000 для среды staging. Это немного неудобно, как и некоторые другие части пользовательского интерфейса Postman, но это возможно;)

Это заняло слишком много времени

Затем мы идем в коллекцию и меняем имена хостов в сохраненных запросах, чтобы использовать {{host}} — метод {{ }} — это то, как Postman обрабатывает переменные среды, и его можно использовать для таких вещей, как ключи API.

Как видите, я изменил имя хоста на `{{host}}/` и использую среду `development`, и все в порядке

Итак, давайте переведем на инструмент newman.

Ах. В порядке.

Таким образом, экспорт коллекции не приносит с собой никаких переменных среды. Мы должны экспортировать их также.

Я оставил схему именования файлов без изменений

И теперь мы собираемся использовать эти конфигурации среды с нашим выполнением newman:

Бум! Контролируемая Git, командная строка выполняла тестирование API в разных средах с использованием инструмента, который все разработчики должны использовать в любом случае для простой проверки после развертывания. Есть очевидные шаги по добавлению этого в ваш конвейер Jenkins/Gitlab/что угодно, которые я не собираюсь здесь описывать, но я доволен тем, что было обнаружено за последние пару часов.

И последнее, давайте поместим это в файл package.json, чтобы мы могли повторно использовать:

{
  "name": "postman-newman-testing",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "config": {
    "environment": "development"
  },
  "scripts": {
    "debug": "nodemon src/index.js",
    "start": "node src/index.js",
    "test": "echo \"Error: no test specified\" && exit 1",
    "test-post-deploy": "newman run ./docs/postman-collection.json -e ./docs/$npm_package_config_environment.postman_environment.json"
  },
  "author": "Chris Williams <[email protected]>",
  "license": "ISC",
  "dependencies": {
    "body-parser": "^1.19.0",
    "express": "^4.17.1",
    "express-request-id": "^1.4.1"
  },
  "devDependencies": {
    "newman": "^4.5.5",
    "nodemon": "^1.19.3"
  }
}

Затем мы можем обрабатывать конфигурации для сред, как нам нравится, и запускать

npm run test-post-deploy

выполнить тест!

Вывод

Хотя это может быть еще один набор тестов и определений для поддержки (мне бы очень хотелось, чтобы это было основано на наших документах спецификации OpenAPI, но я выясню это позже), это, кажется, отличный способ достичь двух вещей:

  1. Очень простой набор тестов для запуска после развертывания или как часть инструментов мониторинга.
  2. Файл коллекции можно передать разработчикам, работающим с API: они все равно будут использовать Postman (вероятно), так что дайте им преимущество.

Postman — это всего лишь один из тех инструментов, которые вы должны использовать, если вы занимаетесь веб-разработкой или разработкой приложений. Учитывая, что это всего лишь «часть» набора инструментов для разработки, мы можем также использовать знакомство и использовать его как часть инструментов тестирования.

Есть некоторые вещи, о которых я хотел бы узнать немного больше:

  • Может быть, иметь возможность сохранять вывод в файле, чтобы он был быстро виден в Jenkins.
  • Установите серьезность отдельных тестов — так, если мы провалим некоторые, это будет мгновенный откат, если мы провалим некоторые другие, это будет громкий клаксон в инженерном бюро, чтобы кто-то расследовал, но это может быть решено путем исправления форвардов.
  • Протестируйте на sad-paths , убедитесь, что правильные коды ответов об ошибках возвращаются для вещей, не создавая для них ответы: я думаю, что есть что-то, что вы можете сделать с помощью Collection Runner и файла образцов данных, а затем отметьте, если тесты должны быть красными или зелеными, но я не стал этого делать.

Спасибо также тем, кто отвечал на мои непрерывные твиты обо всем, что происходит с Почтальоном за последние пару часов, особенно Дэнни Дейнтону, у которого также есть свои собственные статьи Dev.to на https://dev.to. /ДэнниДаинтон»

Еще раз спасибо за комментарии к предыдущим статьям, мне было бы интересно услышать, как вы используете это в своих проектах! Получить меня на https://twitter.com/Scampiuk