Публичные API для практики тестирования

Как пользоваться этим списком публичных API

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

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

Чтобы освоить основы запросов и ответов

• JSONPlaceholder. Учебный REST API с постами, комментариями, пользователями и задачами. Принимает запросы на запись и делает вид, что сохраняет их. Что отрабатывать: CRUD-методы, коды состояния и разницу между успешным запросом и сохранённым изменением. То, что записи на самом деле не сохраняются, делает этот сервис на редкость удачным уроком: проверять нужно результат, а не ответ.

• HTTPBin. Эндпоинт, который возвращает обратно всё, что вы отправили, плюс маршруты, выдающие любой запрошенный код состояния, намеренно задерживающие ответ или отдающие некорректные данные. Что отрабатывать: таймауты, повторные попытки, обработку редиректов и поведение заголовков. Если хотите посмотреть, как ваш набор тестов отреагирует на 503, вы можете получить его по запросу.

• REST Countries. Данные о странах со стабильной, хорошо задокументированной структурой и без необходимости в ключе. Что отрабатывать: проверку схемы и валидацию на уровне полей на ответе, который достаточно большой, чтобы быть интересным, и достаточно маленький, чтобы его можно было прочитать.

Для пагинации и больших коллекций

Для аутентификации и лимитов запросов

Три проверки, которые стоит отработать на любом публичном API

Какой бы сервис вы ни выбрали, именно эти привычки перенесутся на ваш собственный API.

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

• Проверяйте, что ошибки возникают правильно. Запросите то, чего не существует, и убедитесь, что получаете нужный код и пригодную для работы структуру ошибки. Сервисы, которые возвращают 200 с объектом ошибки внутри, встречаются часто, и набор тестов, который об этом не знает, будет вечно показывать зелёный.

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

Как направить на такой API агента

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

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

• Сохраняет ли он значения вместо того, чтобы прописывать их жёстко? Запрос на создание возвращает идентификатор, и следующий вызов должен его использовать. Жёстко прописанные идентификаторы — обычная причина, по которой набор тестов срабатывает ровно один раз.

• Правильно ли он упорядочивает зависимые вызовы? Нельзя получить комментарий к посту, который так и не был создан. Посмотрите, понимает ли это план или просто перечисляет эндпоинты по алфавиту.

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

Если вы предпочитаете владеть кодом тестов, CLI предлагает для бэкенда другой путь: вы сами пишете вызовы и проверки на Python, объявляете, что каждому тесту нужно и что он производит, и оформляете очистку как отдельный тест. Это больше работы на старте, зато набор тестов оказывается в вашем репозитории — одним командам это нужно, другим нет.

От практики к собственному сервису

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

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

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

Чего с ними делать не стоит

• Не используйте их для нагрузочного тестирования. Они бесплатные и общие, но кто-то за них платит.

• Не делайте их зависимостью в продакшене. Условия меняются, проекты уходят в архив, а волонтёры устают.

• Не считайте, что зелёный набор тестов против JSONPlaceholder доказывает корректность вашего собственного API. Он говорит лишь о том, что ваша тестовая обвязка работает, — это действительно полезно, но это куда более скромное утверждение.

Как попробовать это на реальном сервисе

Когда привычка писать проверки становится естественной, переход к собственному API — это тот момент, где начинаются проблемы с состоянием, и именно эту часть TestSprite берёт на себя как продукт. Auto-Authentication поддерживает сессии живыми на протяжении всего прогона. Dynamic Variables переносят идентификатор из запроса на создание в запрос на удаление. Dependency Chains определяют, что должно произойти в первую очередь. Auto-Cleanup удаляет то, что создал прогон.

Начало работы с собственным сервисом выглядит так же, как упражнение с публичным API выше: укажите в проекте базовый URL, дайте обнаружению перечислить эндпоинты и прочитайте сгенерированный план до того, как что-то запустится. Разница в том, что теперь план охватывает авторизацию и граничные случаи, а прогон не оставляет после себя следов.

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