Playwright и MCP: как AI-агент проверяет UI и базу данных без ручных SQL-ассертов

Один зелёный тост после нажатия кнопки «Оформить заказ» ещё не означает, что заказ действительно создан. Если транзакция откатилась, очередь потеряла сообщение, а UI всё равно показал «успешно», end-to-end тест даст ложное чувство надёжности. Именно поэтому всё больше команд смотрят в сторону full-stack верификации, где проверяется не только интерфейс, но и фактическое состояние данных в базе.

В классическом подходе для такой проверки тестовой инфраструктуре нужен прямой доступ к БД через ORM или низкоуровневый драйвер. Дальше начинаются накладные расходы: отдельные учётные данные, настройка соединений, ручные SQL-ассерты, поддержка запросов при каждом изменении схемы. Формально это решает задачу, но цена растёт вместе с числом сценариев.

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

Затем этот же агент переключается на сервер, который умеет читать структуру базы данных и отвечать на проверочные запросы без того, чтобы тестировщик писал SQL вручную. По сути, агенту достаточно сформулировать, что именно нужно подтвердить: существует ли запись заказа, совпадают ли позиции, списался ли остаток товара, изменился ли статус платежа. Такой подход закрывает главный разрыв между «UI показал успех» и «бизнес-операция действительно завершилась».

Агент может сопоставить данные из интерфейса с записями в таблицах, проверить побочные эффекты и даже учесть асинхронность, если система пишет в БД не мгновенно. Для продуктовых команд это особенно важно в сценариях, где одна пользовательская кнопка запускает цепочку действий: создание заказа, резервирование инвентаря, запись в логистическую систему, обновление статуса клиента. Именно в таких местах чаще всего рождаются дорогие баги, которые обычный UI-тест не ловит.

Практическая ценность паттерна в том, что он снижает порог для full-stack тестирования. Команде не нужно тащить в тесты ORM только ради нескольких проверок и дублировать знание о схеме базы в коде ассертов. Вместо этого появляется единый слой проверки на уровне намерений: «после оформления заказа должна появиться запись», «количество позиций должно совпасть», «остаток на складе должен уменьшиться на единицу».

Если схема меняется, поддержка переносится ближе к MCP-серверу или к описанию доступа к данным, а не размазывается по десяткам тестов. В результате тесты становятся короче, понятнее и ближе к языку бизнеса. При этом такой сценарий не отменяет базовую инженерную дисциплину.

Полагаться только на AI-агента нельзя: unit- и integration-тесты всё ещё нужны, чтобы быстро локализовать ошибки на уровне функций, сервисов и контрактов. Доступ к базе для агента должен быть ограничен, лучше read-only и только в тестовой среде. Нужны и меры предсказуемости: стабильные тестовые данные, понятные правила выборки, защита от того, чтобы агент случайно проверял не тот заказ в общей базе.

Иначе удобный инструмент быстро превратится в источник шумных и трудно воспроизводимых падений. Главный вывод здесь простой: следующий шаг в развитии end-to-end тестирования — это переход от проверки экранов к проверке реальных последствий пользовательского действия. Связка Playwright и MCP делает такой переход заметно дешевле, потому что убирает ручной SQL из повседневной работы тестировщика и позволяет одной автоматизации пройти путь от клика по кнопке до факта записи в базе.

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