Playwright and MCP: How an AI Agent Tests UI and Database Without Manual SQL Assertions

Один зелёный тост после нажатия кнопки «Оформить заказ» ещё не означает, что заказ действительно создан. Если транзакция откатилась, очередь потеряла сообщение, а 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 из повседневной работы тестировщика и позволяет одной автоматизации пройти путь от клика по кнопке до факта записи в базе.

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