Code review с AI и тесты: Playwright MCP и авто-ревью PR

Вы научили агента писать код. Теперь закономерный вопрос: а он точно работает? И не сломает ли следующую фичу то, что только что написали? Здесь в игру входят два инструмента — автотесты и code review с AI. В статье разберём, как подключить оба к рабочему процессу: Playwright MCP для e2e-тестов и авто-ревью PR прямо в Claude Code. Плюс самое важное — как читать вывод ревью-агента критически, а не слепо.

Тест — факт. Ревью — мнение

За этой формулировкой — рабочий принцип, который меняет отношение к обоим инструментам.

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

Авто-ревью отвечает на вопрос «нет ли в этом изменении рисков, о которых я не подумал» — вероятностно. Агент может найти настоящий баг. Может выдать шум. Может уверенно написать про «утечку пароля» в строке, где её нет. Всё это — нормальная работа вероятностной системы.

Отсюда правило: тестам доверяем, ревью читаем критически. Это не недостаток AI — это характер инструмента, который нужно понять один раз.

Что стоит делегировать ревью-агенту

Не всё одинаково хорошо поддаётся авто-ревью. Есть зоны, где агент стабильно силён:

• необработанные ошибки и забытый await в асинхронном коде;
• утечка секретов или токенов в логах/коде;
• проверка соответствия конвенциям из CLAUDE.md;
• edge-cases, которые легко забыть: пустой список, неавторизованный запрос, дублирующийся ID.

Есть зоны, где решает человек:

• продуктовые компромиссы («а нужна ли вообще эта фича»);
• бизнес-корректность доменных правил (правильная ли формула расчёта бонусов);
• архитектурные решения с долгосрочными последствиями.

Агент — усилитель внимательного человека, а не его замена.

Playwright MCP: агент с глазами

Обычные автотесты пишутся «вслепую»: автор теста придумывает селекторы, не видя реального DOM. Итог — хрупкие .btn-primary и тесты, которые падают после рефакторинга вёрстки.

Playwright MCP меняет это. Агент подключается к живому браузеру, сам открывает нужную страницу, делает снимок DOM и пишет тест по реальным селекторам — ролям и видимому тексту. Такие тесты устойчивы: они опираются на то, что пользователь видит, а не на детали реализации.

Как это работает на практике — на примере CoffeeCRM (сквозной проект курса: Next.js + NestJS + PostgreSQL, всё локально).

Шаг 1. Установить Playwright.

npm i -D @playwright/test
npx playwright install

Браузеры ставятся локально, один раз. Сеть и платные раннеры не нужны.

Шаг 2. Минимальный конфиг с автозапуском приложения.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './e2e',
  use: { baseURL: 'http://localhost:3000' },
  webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

webServer поднимает CoffeeCRM перед прогоном и сам дожидается готовности. Это «бесплатный CI» на своей машине.

Шаг 3. Промпт агенту с Playwright MCP.

«Открой через Playwright MCP http://localhost:3000/orders, сделай снимок страницы, найди реальные селекторы кнопки ‘Новый заказ’ и формы. Напиши e2e-тест на сценарий: открыть список заказов → создать заказ с позицией ‘Капучино’ → проверить, что он появился в списке. Используй роли и видимый текст, а не CSS-классы.»

Агент открывает страницу, читает DOM и пишет тест по тому, что увидел — а не по тому, что придумал:

import { test, expect } from '@playwright/test';

test('бариста создаёт заказ и видит его в списке', async ({ page }) => {
  await page.goto('/orders');
  await page.getByRole('button', { name: 'Новый заказ' }).click();
  await page.getByLabel('Позиция').fill('Капучино');
  await page.getByRole('button', { name: 'Сохранить' }).click();
  await expect(page.getByRole('row', { name: /Капучино/ })).toBeVisible();
});

Если тест флакает — лечим ожиданием события (toBeVisible()), а не waitForTimeout. Пауза фиксированной длины — симптом того, что тест не знает, когда готово.

Шаг 4. Прогнать.

npx playwright test           # обычный прогон
npx playwright test --headed  # с видимым браузером для отладки
npx playwright test --ui      # интерактивный режим

Про подключение Playwright MCP и других серверов подробнее — в статье Как подключить MCP-серверы.

Авто-ревью PR: запустить и прочитать правильно

Когда тест зелёный и изменение готово к PR — запускаем ревью-агента. В Claude Code это делается командой /review внутри диалога, либо прямым промптом:

«Проведи ревью текущего диффа: риски, баги, безопасность, что проверить руками.»

Агент возвращает структурированный отчёт. И вот здесь начинается самое важное — сортировка.

Вывод ревью нужно разложить на три кучки:

1. Осмысленное замечание — берём в работу. Агент пишет: «В обработчике создания заказа не покрыт случай пустой корзины — вернётся 500 вместо 400». Открываем код, проверяем — баг реальный. Заводим фикс.

2. Шум — игнорируем с объяснением. «Рекомендую добавить JSDoc ко всем функциям». Не относится к изменению, не наша конвенция. Отклоняем — и записываем в комментарий к PR, почему.

3. Галлюцинация — ловим и проверяем. «Утечка пароля БД в order.service.ts:42». Звучит тревожно. Открываем файл на строке 42 — там ничего подобного нет.

Правило: любое заявление ревью про конкретное место в коде проверяется открытием этого места. Занимает десять секунд. Это и есть критическое чтение.

Решение фиксируем в комментарии к PR: что приняли, что отклонили, почему. Не «агент сказал — сделали», а осознанный выбор с обоснованием.

Как это встраивается в рабочий процесс

На реальном проекте цепочка выглядит так:

1. Агент пишет фичу через spec-kit (об этом — в статье SpecKit: поток).
2. Playwright MCP пишет e2e-тест по реальному сценарию — тест зелёный.
3. Открываем PR, запускаем /review, читаем критически, фиксируем решение.
4. Перед коммитом — хуки-гейты, которые прогонят тесты автоматически (подробнее в статье Хуки и гейты качества).

Тесты как факт, ревью как мнение — это не два разных инструмента, а две дополняющие петли качества. Вместе они дают уверенность, которую нельзя получить ни от одной из них по отдельности.

Вывод

Code review с AI и автотесты — это инфраструктура, которая позволяет двигаться быстро и не бояться сломать. Агент пишет тест по реальному DOM через Playwright MCP — опираясь на факты, а не на догадки. Ревью находит проблемы, которые легко пропустить на усталом взгляде. Читать его критически — такой же навык, как писать хороший промпт.

Если хотите разобрать это системно — от первой команды до CI-пайплайна на реальном fullstack-проекте — смотрите полный курс по Claude Code.