Как full-stack верификация тестов через MCP ловит ошибки данных

Full-stack верификация тестов через MCP с Playwright и базой данных без SQL — когда UI вводит в заблуждение

Зелёный CI не гарантирует, что данные записаны. Интерфейс может пройти, а записи в таблицах — нет. Поэтому тест «интерфейс работает» часто не равен «результат сохранён».

Решение — один агентный сценарий. Через Playwright MCP он берёт order ID со страницы подтверждения. Затем через PostgreSQL MCP проверяет запись в базе — без ручного SQL. Это переводит проверку с кликов на инварианты данных и снижает регрессионные риски.

Сценарий практический. Агент извлекает «Order #10472», изучает схему через list_tables и describe_table и сам формирует запрос. Он проверяет строку в orders с email ada@test.dev и связанную запись в line_items для товара «Wireless Charger» с количеством 1. Доступ — только read-only. Для асинхронных операций — опрос до 5 секунд с шагом 500 мс.

Дальше разберём шаги агента, ограничения доступа и работу с задержками.

Почему UI-тесты пропускают ошибки в данных

Кажется, если UI прошёл — всё хорошо. CI зелёный, сценарий кликов выполнен.

Но визуальный успех может скрывать пустую базу. Страница показывает Order #10472, а строки в orders или line_items нет.

Проблема в фокусе на действиях, а не на данных. Тесты фиксируют клики, но не проверяют инварианты. В итоге e2e даёт иллюзию качества.

Практика: баг попадает в прод. Команда тратит часы на разбор. Доставка задерживается, поддержка получает жалобы. Причина — отсутствие записи, а не ошибка в UI.

Нужен сценарий, который после UI возвращается к базе и проверяет фактическое состояние через Playwright MCP и PostgreSQL MCP.

Как работает проверка UI→DB через MCP

Шаги агента

Агент ведёт сценарий в браузере через Playwright MCP. Доходит до страницы подтверждения извлекает order ID, например «Order #10472». Затем переключается на PostgreSQL MCP и проверяет данные.

Перед запросами он изучает схему. Вызывает list_tables и describe_table, чтобы понять таблицы и поля. После этого сам формирует корректный SQL и выполняет его от read-only пользователя.

Пример запроса, который он может собрать:

SELECT 1 FROM orders WHERE id = 10472 AND email = 'ada@test.dev';

SELECT 1 FROM line_items WHERE order_id = 10472 AND product = 'Wireless Charger' AND qty = 1;

Если система асинхронна, агент ждёт. Он опрашивает базу до 5 секунд с интервалом 500 мс, пока записи не появятся.

Ключ — связать ID из UI с реальными строками в базе и проверить обе таблицы.

Почему это работает

UI и база — разные слои. Доступ к ним дают разные MCP: Playwright — к интерфейсу, PostgreSQL — к данным. Разрыв между слоями и даёт ошибки.

Автоматическая генерация SQL убирает ручные запросы. Агент сначала читает схему, затем строит корректные условия и JOIN. Это снижает ошибки выбора полей.

Асинхронность создаёт ложный успех. Интерфейс показывает ID раньше записи. Поэтому нужна логика ожидания с опросом.

Read-only доступ защищает данные. Проверки не могут изменить состояние, но видят факты.

К чему это приводит

Критерий успеха меняется. Важны не клики, а состояние данных.

Один сценарий описывается одной инструкцией. Тот же подход работает с MySQL MCP без смены логики.

Требование одно — аккуратно настроить доступ и ожидания. Иначе возможны ложные результаты.

Что это даёт на практике

Надёжная e2e-верификация — это цепочка: UI → извлечение ID → интроспекция схемы → проверка в БД через MCP.

Дальше — конкретным ситуациям и ошибкам.

Где подход ловит реальные сбои

Ночной прогон CI

CI зелёный, есть страница с Order #10472. Команда считает покупку успешной.

В проде клиент не получает товар. В логах нет записи в line_items.

Итог — срочное расследование и сдвиг доставок. Проверка UI это не поймала.

Локальная отладка

Инженер пишет запрос «по памяти» к orders.

Получает пустой результат или неверные поля из‑за ошибки в JOIN.

Тратит часы на правки. Агентный подход сначала читает схему и собирает корректный запрос сам.

Асинхронная запись

Интерфейс показывает подтверждение сразу.

Данные пишутся с задержкой или не пишутся вовсе.

Без ожидания тест даёт ложный успех. Опрос до 5 секунд решает проблему.

Что меняется в результате

Зелёный CI больше не вводит в заблуждение. Агент берёт order ID и проверяет его в базе: строку в orders и запись в line_items.

Вы получаете проверку результата, а не кликов. Это снижает риск «невидимых» дефектов и ускоряет разбор инцидентов.

Практический эффект: меньше ручных запросов и правок. Агент читает схему через list_tables и describe_table и сам генерирует SQL. Ожидание ограничено: до 5 секунд с шагом 500 мс.

Итог — тот же объём тестов даёт более точный критерий успеха: данные соответствуют ожиданиям.

Как начать применять подход

UI-тесты без проверки базы дают ложную уверенность. Подтверждение на экране не гарантирует записи в orders и line_items.

Рабочее решение — связать UI и БД одним сценарием. Агент через Playwright MCP берёт order ID, читает схему (list_tables, describe_table), сам собирает SQL и проверяет данные через PostgreSQL MCP с read-only доступом. Учитывает задержки: опрос до 5 секунд с шагом 500 мс.

Почему это надёжно: проверяется результат, а не действия. Авто‑SQL снижает ошибки. Интроспекция исключает неверные поля. Read-only защищает данные.

С чего начать: возьмите один критичный e2e‑сценарий и добавьте шаг проверки в БД через MCP после получения order ID.

Так вы переходите к full‑stack критерию успеха: UI→DB.

Вопросы по внедрению