🤖 Что это
AI Regression Testing — это стратегия регрессионного тестирования для проектов, где код пишет и ревьюит одна и та же AI-модель (например, Claude Code или Cursor). Такой цикл создаёт системные слепые зоны: AI повторяет одни и те же ошибки, потому что на этапе ревью исходит из тех же предположений, что и при написании. Этот подход предписывает писать автоматические тесты не на работающий код, а на уже найденные баги — и запускать их первым делом при каждом баг-чеке. Результат: типовые регрессии перестают возвращаться.
⚙️ Как работает
🧪 Песочница для тестов без БД
Большинство современных проектов имеют режим sandbox — окружение с моками вместо реальной базы данных. Этот режим активируется переменной окружения (например, SANDBOX_MODE=true) и позволяет запускать тесты API мгновенно, без зависимостей. Технически это делается в файле настройки Vitest:
# __tests__/setup.ts — принудительно включаем песочницу
process.env.SANDBOX_MODE = "true";
process.env.NEXT_PUBLIC_SUPABASE_URL = "";
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY = "";
Для имитации HTTP-запросов к Next.js App Router создаётся вспомогательная функция createTestRequest, которая формирует объект NextRequest с нужными заголовками и телом. Песочница также подменяет ID текущего пользователя через заголовок x-sandbox-user-id.
🎯 Тестируем только то, что ломалось
Главный принцип: тесты пишутся на конкретные баги, а не «на всякий случай». Если баг был найден в ручке /api/user/profile — тест пишется для этой ручки. Если в /api/user/favorites багов не было — тест для неё не нужен. Почему это работает: AI склонна повторять один и тот же тип ошибок в сложных местах (авторизация, расходящиеся пути, управление состоянием). Один тест навсегда блокирует целый класс регрессий.
// Пример: тест на конкретный баг BUG-R1 (notification_settings пропадало из ответа)
it("notification_settings is not undefined (BUG-R1 regression)", async () => {
const req = createTestRequest("/api/user/profile");
const res = await GET(req);
const { json } = await parseResponse(res);
expect("notification_settings" in json.data).toBe(true);
});
🧰 Встроенный баг-чек-воркфлоу
Весь процесс зашит в кастомную команду /bug-check. Шаги выполняются строго последовательно:
npm run test — Vitest. Если упал → ошибка механическая, ревью не нужно.
npm run build — TypeScript + сборка. Если ошибка → типовая, тоже без ревью.
- AI-ревью кода — с учётом известных слепых зон: согласованность sandbox/production, полнота
SELECT, обработка ошибок, rollback при optimistic update.
- На каждый найденный баг — пишется регрессионный тест, который будет запускаться при следующем
/bug-check.
🧠 Типовые AI-регрессии и как их ловить
📍 Несогласованность путей Sandbox / Production
Самая частая проблема (75% наблюдений). AI добавляет новое поле в ответ на продакшен-пути, но забывает сделать то же самое в песочнице.
test("sandbox and production return same fields", async () => {
const res = await GET(createTestRequest("/api/user/profile"));
const { json } = await parseResponse(res);
for (const field of REQUIRED_FIELDS) {
expect(json.data).toHaveProperty(field);
}
});
🧩 Пропущенные поля в SELECT
При работе с Supabase / Prisma AI часто добавляет поле в ответ, но не включает его в .select(...). В результате поле всегда undefined. Тест просто проверяет наличие всех ожидаемых полей в ответе — и регрессия поймана.
⚠️ Утечка состояния при ошибке
При добавлении обработки ошибок AI может забыть очистить старые данные. Например, при переключении вкладок — старый список заказов остаётся в стейте, хотя запрос упал. Тест: симулировать ошибку и проверить, что данные сброшены.
🔄 Отсутствие rollback при optimistic update
AI реализует optimistic update (удаляем элемент из UI сразу), но не возвращает его обратно, если API вернул ошибку. Тест проверяет: после неудачного DELETE состояние восстанавливается.
🗺️ Когда использовать
- AI-агенты пишут и ревьюют код — особенно Claude Code, Cursor, Codex.
- Проект имеет режим sandbox / mock — это ускоряет тесты до миллисекунд.
- Вы уже поймали 1–2 регрессии, которые AI пропустила на ревью — стратегия окупается с первого же бага.
- Команда использует
/bug-check как обязательный шаг перед мержем PR.
⚠️ Важно знать
- Не гонитесь за процентом покрытия. Бесполезные тесты на стабильные участки только замедляют цикл.
- Не полагайтесь на AI-ревью как на замену тестам. Если AI написала код, она не заметит свою же ошибку.
- Тесты должны быть быстрыми — вся пачка регрессионных тестов в песочнице должна отрабатывать менее чем за секунду.
- Именуйте тесты по номеру бага (BUG-R1, BUG-R2) — это упрощает поиск и аудит.
Комментарии
Комментариев пока нет. Будьте первым.