Postman и TestSprite: коллекции против сгенерированного покрытия

Сразу вывод

• Выбирайте Postman, если вы исследуете API, документируете его или делитесь воспроизводимыми запросами с людьми, которые не будут писать тестовый код.

• Выбирайте TestSprite, если вам нужно покрытие API, которое генерируется из того, что сервис действительно предоставляет, и в котором работа с сессией, состоянием, порядком выполнения и очисткой встроена в сам продукт.

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

Бок о бок

Механика этих четырёх описана в документации по тестированию API.

В чём Postman действительно лучше

• Исследование незнакомого API. Ничто не сравнится с ручными запросами к эндпоинтам, пока вы только разбираетесь, что они делают.

• Передача сценария воспроизведения. Коллекция, которую можно импортировать и запустить, — самый понятный баг-репорт, какой может получить команда, отвечающая за API.

• Живая документация. Запросы, которые одновременно служат примерами и лежат рядом с тем API, который они описывают.

Где коллекции со скриптами обходятся дорого

Любая серьёзная коллекция со временем обрастает слоем pre-request- и тестовых скриптов, которые работают с токенами, извлекают идентификаторы, задают порядок и выполняют очистку. Это небольшой фреймворк на JavaScript, встроенный в инструмент, который фреймворком быть не задумывался, и обычно понятный лишь одному человеку.

Это работает. Цена в том, что человек, который в этом разбирается, сам становится зависимостью, а коллекцию, когда она краснеет, чаще отправляют в карантин, чем чинят.

Когда коллекция и есть документация

Есть случай, когда коллекция делает то, чего не заменит ни один сгенерированный набор тестов, — и её стоит защитить, а не убрать ради консолидации.

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

Чистое разделение выглядит так: коллекция — это парадный вход, а страховочной сеткой пусть будет что-то другое. Эти задачи тянут в разные стороны, и попытка заставить один артефакт делать и то и другое — причина того, почему столько коллекций в итоге не оказываются ни читаемыми, ни надёжными.

Как использовать оба

Оставьте коллекцию для исследования, документации и воспроизведения багов. Пусть сгенерированное покрытие отвечает за эндпоинты и интеграционные цепочки, которые должны продолжать работать. На практике они почти не пересекаются, потому что отвечают на разные вопросы.

Если вы выбираете инструмент, сломайте что-нибудь намеренно

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

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

Что берёт на себя TestSprite и чего не должна делать коллекция

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

Покрытие строится из API Discovery по работающему сервису плюс вашей спецификации, что даёт сценарии ошибок и граничные случаи, которые собранные вручную коллекции пропускают. Уточняете вы его обычным языком, а не в pre-request-скриптах.

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