Что Playwright делает правильно в API-тестировании
Полноценный контекст запросов. Вызовы API не требуют страницы браузера, поэтому проверки выполняются со скоростью запроса.
Переиспользуемое состояние авторизации. Войдите один раз, сохраните состояние и переиспользуйте его во всех тестах. Это самое значимое практическое улучшение по сравнению со старыми фреймворками.
Один и тот же раннер для обоих уровней. Один репортер, одна CI-задача, один способ всё запускать. Это недооценивают ровно до тех пор, пока поддерживать всё это не приходится вам.
Для команды, которая уже живёт в Playwright и которой нужно умеренное покрытие API, это действительно хороший вариант.
Где он перестаёт помогать
Сохранённое состояние устаревает
Сохранённая авторизация — это снимок. Токены истекают, а логику их обновления вам придётся написать и поддерживать самим.
Зависимости между данными
Какой тест создаёт запись, нужную другому, и что произойдёт, когда первый упадёт.
Всё это задаётся вручную — фикстурами, порядком выполнения и пропусками тестов.
Очистка при параллельном запуске
Playwright по своей архитектуре запускает тесты параллельно, из-за чего очистка по шаблону становится небезопасной.
Очистка должна быть привязана к тому, что создал конкретный прогон.
Ничто из этого не является дефектом фреймворка. Это те части API-тестирования, которые ни один раннер не решает за вас, и именно они составляют бо́льшую часть затрат в долгосрочной перспективе.
Покрытие, ограниченное тем, о чём вы вспомнили
Менее заметная проблема в том, что написанный вручную набор тестов покрывает те эндпоинты, о которых кто-то вспомнил. Коды ошибок, граничные значения и редко используемые параметры — это как раз то, что ломается, и как раз то, что никто не пишет в одиннадцать вечера.
Генерация покрытия из спецификации или по результатам обхода работающего сервиса меняет саму форму покрытия, а это важнее, чем эргономика любой отдельной проверки.
Что берёт на себя специализированный слой
Переживёт ли набор API-тестов свой первый год, решают четыре вещи — с любым инструментом: истекающие сессии, значения, которые существуют только во время выполнения, вызовы, зависящие друг от друга, и записи, которые никто не удаляет. В TestSprite это называется Auto-Authentication, Dynamic Variables, Dependency Chains и Auto-Cleanup, а документация по API-тестированию описывает механику работы.
Чего сохранённое состояние не переживает
Переиспользование сохранённого состояния авторизации — главное эргономическое преимущество Playwright в работе с API, и у него есть три острых угла, о которых стоит знать, прежде чем на нём строить.
Сохранённое состояние — это снимок, поэтому всё, у чего короткое время жизни токена, истечёт посреди прогона и даст падения, неотличимые от ошибок авторизации. Сохранённое состояние также принадлежит одному пользователю, поэтому любому тесту, которому нужен второй аккаунт для проверки прав, придётся готовить его отдельно. И сохранённое состояние фиксирует то окружение, для которого оно было создано: если направить набор тестов на staging с файлом состояния из локального окружения, вы получите особенно запутанный класс падений.
Ни то, ни другое, ни третье не повод от него отказываться. Это причины, по которым в проекте со временем появляется небольшой модуль для управления файлами состояния — по пользователям и по окружениям. И это тот момент, когда вы начали строить ровно то, чего пытались не строить.
Как запускать их вместе
Оставьте Playwright для браузерных сценариев и для межуровневых проверок, где действительно нужны обе стороны в одном тесте. Широту покрытия по всей поверхности API отдайте сгенерированным тестам. Оба набора запускаются из одного пайплайна, ничего не зная друг о друге.
GitHub App — это вебхук, который вы настраиваете в дашборде TestSprite. Он слушает событие деплоя, которое ваш пайплайн уже создаёт, поэтому в репозитории ничего не меняется.
GitHub Actions встраивает нужный шаг прямо в ваш workflow и настраивается из терминала. Актуальные команды — в репозитории CLI.
Где эстафету принимает TestSprite
За Playwright остаются браузерные сценарии и межуровневые тесты. TestSprite берёт на себя широту покрытия и работу с состоянием — то есть ровно те части, которые остаются на вас, каким бы хорошим ни был контекст запросов.
Конкретно это означает: Auto-Authentication вместо модуля для работы с сохранённым состоянием, который вы поддерживаете для каждого пользователя и каждого окружения; Dependency Chains вместо фикстур и соглашений о порядке выполнения; Auto-Cleanup, привязанная к каждому прогону, вместо удаления по префиксу, которое ещё должно быть безопасным при параллельном запуске. Покрытие берётся из вашей спецификации и работающего сервиса, а не из того, что кто-то вспомнил написать.
В результате те полдня, потраченные на вспомогательный код, не превращаются в чью-то постоянную обязанность — а именно она, а не само написание, всегда и была настоящей ценой.
Достаточно ли Playwright самого по себе для API-тестирования?
Для умеренной поверхности API и команды, которая её поддерживает, — да. Вопрос в том, готовы ли вы взять на себя обновление сессий, порядок зависимостей и безопасную при параллельном запуске очистку, потому что всё это идёт в комплекте.
Решает ли сохранённое состояние проблему авторизации?
Оно решает проблему повторов, но не истечения срока. Сохранённое состояние — это снимок, и что-то всё равно должно его обновлять.
Могут ли оба набора тестов использовать одни учётные данные?
Делите источник, а не сессию. Когда каждый уровень получает собственную сессию, падение в одном не тянет за собой другой.
А что насчёт контрактного тестирования?
Другой инструмент. Контрактное тестирование проверяет, что два сервиса согласованы по схеме; здесь же проверяется, что работающий сервис ведёт себя корректно.
Не будет ли сгенерированное покрытие дублировать наши тесты?
Небольшое пересечение — это нормально и обходится дёшево. Направьте сгенерированный слой на широту покрытия, а написанные вручную тесты оставьте для сценариев, которые вы описали осознанно.
Отличная эргономика, та же проблема состояния.
API-тестирование в Playwright убирает бо́льшую часть трения, свойственного другим фреймворкам. Остаются время жизни сессии, зависимости между данными и безопасная при параллельном запуске очистка, плюс покрытие, ограниченное тем, что кто-то вспомнил написать. Оставьте Playwright для сценариев, а широту покрытия доверьте специализированному слою.