Когда я первый раз попросил Cursor «напиши тесты для этой функции» — он выдал два теста на happy path, без моков, без edge-кейсов. Проверка ошибок — ноль. Покрытие — процентов двадцать. Я понадеялся на ИИ, задеплоил, и через неделю сломал прод одной строкой в бизнес-логике. Без тестов. Без защиты.

С тех пор у меня выработался подход: ИИ не должен писать «пару assert-ов». Он должен создавать полноценную структуру — unit, integration, snapshot, моки внешних сервисов, и сам прогонять тесты, фикся то, что упало. В этой статье — как этого добиться, какие семь правил работают, и что за магия в универсальном мета-промпте.

Ключевое правило: тесты — это не «проверка, что код работает». Это страховка от регрессий и лицензия на рефакторинг. Без тестов вы боитесь трогать собственный код. С тестами — спокойно переписываете его каждый месяц.

Почему обычные промпты дают слабые тесты

Типичный запрос «напиши тесты для этой функции» приводит к предсказуемому результату: ИИ выдаёт два-три теста, проверяет основной сценарий и забывает про всё остальное. Нет моков, нет проверки ошибок, нет edge-кейсов. Покрытие — процентов 20-30.

Причина простая: в промпте не было инструкции, как именно писать тесты. ИИ выбирает самый дешёвый путь — happy path. Чтобы получить полноценную структуру, нужно явно проговорить: какие типы тестов нужны, какие моки, какое покрытие, как запускать и фиксить. Это и есть мета-промпт.

Как это работает технически

ИИ видит три слоя информации: ваш код, требования через промпт, и контекст проекта через AGENTS.md или Custom Instructions в Cursor. Дальше он анализирует: что делает функция, какие у неё входы и выходы, какие внешние сервисы она вызывает (Claude API, Supabase, Telegram), и какие ошибки могут возникнуть.

На выходе ИИ создаёт: файл \*.test.ts рядом с исходником, моки для внешних вызовов, набор тестов с покрытием 80-100 процентов, и инструкцию по запуску. Cursor и Windsurf умеют сами прогонять тесты и фиксить то, что упало — это ещё один уровень автоматизации.

Семь правил, которые работают в 2026 году

Правило 1. TDD-подход: тесты сначала

Самый мощный шаблон: сначала просите ИИ написать тесты ДО кода, и только потом — реализацию. Это переворачивает привычную логику, но даёт лучший результат: тесты заставляют ИИ думать о требованиях, а код становится производной от тестов.

Правило 2. Полное покрытие плюс моки внешних сервисов

Любой вызов внешнего API — Claude, Supabase, Telegram, платёжка — должен быть замокан. Без моков тесты становятся интеграционными, зависят от сети и ломаются по причинам, не связанным с вашим кодом. В промпте явно указывайте: замокать все вызовы внешних сервисов.

Правило 3. Интеграционные тесты, не только unit

Unit-тесты проверяют функции в изоляции. Integration-тесты проверяют, что модули корректно работают вместе. Вторые важнее для бизнес-логики: unit может быть зелёным, а API возвращать 500, потому что два слоя не договорились о формате данных. В промпте явно просите «написать integration-тесты для критических путей».

Правило 4. Автоматический запуск и исправление

Cursor и Windsurf умеют сами запускать тесты после генерации. Если что-то упало — ИИ читает вывод, находит причину, фиксит и прогоняет заново. Это экономит 10-15 минут ручной работы на каждый файл. В промпте пишите: «после генерации запусти тесты, и если есть ошибки — пофикси и перезапусти».

Правило 5. Генерация тестов для всего проекта сразу

Когда проект свежий, проще сразу сгенерировать тесты для всех ключевых модулей, чем добавлять их по одному. ИИ справляется с десятком файлов за один проход, если правильно поставить задачу. В промпте указывайте: «для всех функций в src/services/ создай тесты». ИИ сам обойдёт директорию.

Правило 6. CI/CD-ready тесты

Тесты, которые не запускаются автоматически — мёртвые тесты. С самого начала пишите их так, чтобы GitHub Actions или GitLab CI мог их подхватить: фиксированные имена файлов, npm run test как точка входа, exit code 0 при успехе. Это правило бесплатное, но экономит недели настройки пайплайна потом.

Правило 7. Документация тестов

Каждый тест-блок должен иметь комментарий в одну строку: что проверяем и зачем. Через полгода вы вернётесь к тесту и поймёте, что именно он страхует, без перечитывания всей функции. Это правило дисциплинирует и ИИ, и вас.

Универсальный мета-промпт, который я использую каждый день

Копируйте и адаптируйте под свой стек. Для Next.js замените vitest на jest, для Python — на pytest. Остальное работает как есть:

Ты — инженер по тестированию. Сгенерируй полный набор тестов для функции или модуля [ИМЯ].

1. Сначала проанализируй: что делает функция, какие входы/выходы, какие внешние сервисы вызывает, какие ошибки может бросать.
2. Напиши тесты в файле [ПУТЬ]/[ИМЯ].test.ts:
   - unit-тесты для всех публичных функций (happy path);
   - edge-кейсы (пустые входы, граничные значения, невалидные типы);
   - тесты на ошибки (что функция корректно бросает или возвращает при сбое);
   - integration-тесты, если функция вызывается из других модулей.

3. Замокай все внешние сервисы (HTTP, БД, очереди, сторонние API). Моки положи в __mocks__/ рядом с тестом.
4. Используй vitest (или jest) и TypeScript. Покрытие — минимум 85 процентов по строкам.
5. Каждый тест-блок начинай с однострочного комментария: что проверяем и почему.
6. После генерации запусти npm run test. Если есть ошибки — пофикси код теста (не продакшн-код!) и перезапусти.
7. В конце выведи отчёт: сколько тестов прошло, сколько упало, какое покрытие.

В моей практике этот промпт превращает 2 теста за 3 минуты в 12 тестов за 4 минуты. Соотношение 6 к 1. И это консервативная оценка для свежего кода; для сложной логики выгода растёт.

Чек-лист перед тем, как считать проект готовым

  • для каждой ключевой функции есть свой .test.ts или .spec.ts
  • покрытие строк — не меньше 85 процентов
  • все внешние API замоканы, тесты не зависят от сети
  • есть integration-тесты для критических путей пользователя
  • GitHub Actions запускает тесты на каждый PR и блокирует merge при падении
  • тесты запускаются локально за <10 секунд — иначе перестанете их гонять

Главная мысль

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