Тестирование API: что делать сначала, что потом и что пока не нужно

Пять видов работ внутри тестирования API

• Функциональное. Делает ли отдельный эндпоинт то, что нужно, в том числе при некорректных входных данных. Начинайте отсюда. Всё остальное это подразумевает.

• Интеграционное. Приводят ли последовательности вызовов к правильному результату. Именно здесь на самом деле живёт большинство заметных пользователю багов.

• Контрактное. Согласны ли два сервиса относительно формата данных. Полезно при независимых развёртываниях и ничего не говорит о корректности.

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

Порядок, в котором их стоит выполнять

1. Функциональное — на эндпоинтах, которые имеют значение. Включая негативные сценарии. На этом строится всё остальное.

2. Интеграционное — на ваших реальных пользовательских сценариях. По три-пять шагов в каждом, а не по двенадцать.

3. Проверки авторизации везде. Это дёшево, а авторизация на уровне объектов — самая часто эксплуатируемая уязвимость API.

4. Контрактное — если сервисы развёртываются независимо. Если вы выкатываете всё одновременно, пропустите его.

5. Нагрузочное — перед релизами. В последнюю очередь, потому что нагрузочное тестирование некорректного эндпоинта измеряет лишь то, как быстро вы можете выдавать неверный результат.

Четыре проблемы — какой бы инструмент вы ни выбрали

Переживёт ли набор API-тестов первый год, решают четыре вещи: истекающие сессии, значения, которые существуют только во время выполнения, вызовы, зависящие друг от друга, и записи, которые никто не убирает. В TestSprite за это отвечают Auto-Authentication, Dynamic Variables, Dependency Chains и Auto-Cleanup, описанные в документации по тестированию API.

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

Проверка, которая важнее всего

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

Первые десять тест-кейсов, конкретно

Если набор тестов пуст, самое сложное — решить, с чего начать, а общий ответ отнимет неделю. Вот список, который подходит большинству продуктов.

Три — на главный объект вашего продукта: создать его, получить обратно и проверить поля, удалить и убедиться, что его больше нет. Два — на авторизацию: тот же запрос без учётных данных и с учётными данными другого пользователя. Два — на входные данные: отсутствующее обязательное поле и значение вне допустимого диапазона. Два — на ту последовательность, из-за которой вы нервничаете перед релизом, какой бы она у вас ни была. Один — на эндпоинт, который сломался в прошлый раз.

Десять тест-кейсов, работы на одно утро, и они закрывают те ситуации, из которых вырастает большинство инцидентов. Дальше расширяться стоит от того, что действительно ломается, а не в сторону целевого показателя покрытия: второй подход даёт большие наборы тестов, которые бьют мимо цели.

С чего начать сегодня

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

Если вы предпочитаете ничего не устанавливать, то же самое можно сделать в панели управления. Всё остальное, что умеет командная строка, описано в репозитории CLI.

• GitHub App — это вебхук, который вы настраиваете в панели управления TestSprite. Он слушает событие развёртывания, которое ваш пайплайн уже генерирует, поэтому в вашем репозитории ничего не меняется.

• GitHub Actions встраивает этот шаг в ваш собственный workflow и настраивается из терминала.

Какое место TestSprite занимает среди этих пяти

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

Auto-Authentication поддерживает сессии живыми на протяжении всего прогона, Dynamic Variables переносят значения между вызовами, Dependency Chains выводят порядок выполнения из того, что каждый тест-кейс требует и что производит, а Auto-Cleanup удаляет ровно то, что создал прогон. Именно эти четыре вещи решают, переживёт ли набор тестов первый год, в любом инструменте, и когда они встроены в продукт, вы расширяете набор тестов, а не обслуживаете его.

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