Выбор инструментов автоматизации тестирования API: пять вопросов

1. Кто напишет двухсотый тест?

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

Если ответ — «инженер, вручную», честно спросите себя, есть ли у вас такой инженер. Большинство заброшенных наборов тестов забросили именно здесь.

2. Что происходит, когда истекает сессия?

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

3. Откуда инструмент знает порядок?

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

4. Что остаётся после него?

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

5. Как выглядит сбой для того, кто будет его чинить?

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

Как на эти вопросы отвечают категории инструментов автоматизации тестирования API

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

Шестой вопрос — для команд, у которых в процессе участвует агент

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

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

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

Как на самом деле проводить оценку

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

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

Если пайплайном владеет другая команда, то GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда сборка сообщает, что новая версия выкачена. Если же вы хотите видеть проверку в самом репозитории, то шаг GitHub Actions справится с этим.

Как на эти пять вопросов отвечает TestSprite

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

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

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