Агент, который генерирует тесты, к утру сдаёт сотню зелёных кейсов, — и это начинает мешать: серия растёт, а понять, что она защищает, нельзя. В начале сентября 2026 года появился проект, который разворачивает агента в обратную сторону — не «напиши ещё тестов», а «вырежи бесполезные и объясни, почему». Два навыка Mira Test Engineer удаляют циркулярные ассерты, замоканные проверки и случайные copy-тесты, оставляя только то, что защищает важное поведение. Разбор — ниже.
Покрытие выросло — тесты не защищают
Генерация тестов агентом обходится почти даром, и именно в этом корень проблемы. Агент оптимизирует видимую метрику — число тестов, зелёный прогон, процент покрытия — и производит ассерты, слишком слабые, чтобы поймать неверное поведение. Это не досужее рассуждение: авторы Mira Test Engineer собрали в документе с примерами проблем жалобы разработчиков на сгенерированные тесты и свели их в повторяющиеся паттерны.
| Паттерн провала | Как выглядит на практике |
|---|---|
| Высокое покрытие, слабая уверенность | Тесты добирают строки кода, но ассерт не отличит ошибку от правильной работы |
| Тест повторяет реализацию | Ожидаемое значение вычислено из того же кода, что и проверяется, — круговая проверка |
| Поведение замокано | Мок — одновременно стимул и оракул: тест проверяет искусственную настройку, а не границу системы |
| Случайные проверки текста | Ассерт на точную формулировку заголовка или копию: правка текста роняет тест, баг остаётся зелёным |
| Пустые ассерты | assert result is not None — синтаксис правдоподобен, проверки нет |
| Ассерты, которые не исполняются | Асинхронный сбой происходит после завершения раннера; негативная проверка зелёная, когда локатор ничего не нашёл |
| Инфляция сопровождения | Тесты на тривиальные присваивания и фреймворк: любое изменение кода ломает серию, сигнал исчезает |
Вывод авторы формулируют жёстко: «зелёный результат доказывает только, что раннер завершился, — а не что ассерт выполнился, попал в нужный объект и поймал бы регрессию». Покрытие линии кода слабо коррелирует с обнаружением дефектов — это подтверждают и исследования, на которые ссылается документ, от обзора Dakhel et al. до свежих замеров 2026 года.
Mira Test Engineer: два навыка вместо «добавь ещё тестов»
Проект haukebri/mira-test-engineer (MIT-лицензия, опубликован в начале сентября 2026 года) — это два навыка для агентов, а не очередной генератор:
| Навык | Когда применять |
|---|---|
| Clean Test Suite | Запрошенное ревью и удаление существующих плохих тестов с обязательным одобрением человека |
| Write Good Tests | Постоянная политика: короткие напоминания подгрузить навык перед тестовой работой и код-ревью |
Суть проекта — одна фраза из README, вокруг которой строится весь workflow:
High coverage does not mean useful coverage. This skill removes circular assertions, mocked-away behavior, incidental copy checks, ineffective assertions, and redundant workflows. Tests earn their place by protecting important behavior or genuinely fragile paths.
Перевод: «Высокое покрытие не означает полезное покрытие. Этот навык удаляет циркулярные ассерты, замоканное поведение, случайные проверки текста, неэффективные ассерты и избыточные workflow. Тесты зарабатывают своё место, защищая важное поведение или действительно хрупкие пути».
Скиллы — это просто Markdown с Agent Skills frontmatter: без MCP-сервера, зависимостей и специфичных для хоста инструментов. Их можно поставить в любой кодинг-агент, который умеет читать скиллы: Claude Code, Codex, Pi и DeepSeek Harness.
Как Clean Test Suite чистит набор: шесть шагов
Первое, что делает навык, — читает продакшн-код и требования, и только потом берётся за тесты. Не наоборот: без понимания, что система должна делать, тест невозможно оценить. Дальше порядок такой:
- Понять код и требования. Строится модель проекта — что за приложение, какие данные и логика важны.
- Сопоставить тесты с потоками. Каждый тест привязывается к пользовательским, data- и логическим потокам.
- Оценить ассерты. Качество, релевантность и пересечения; пробелы фиксируются честно, а не прикрываются.
- Предложить точный план удалений — с указанием, какая частичная защита теряется.
- Дождаться одобрения человека. Применять чистку без явного согласия на конкретный план нельзя.
- Применить и верифицировать. Выживший набор запускается; отчёты и артефакты восстановления сохраняются.
Артефакты ложатся в .test-review/ в проекте, который чистится, а не в центральные docs/. Основные файлы — project-model.md (модель кода и требований), test-audit.md (сопоставление тестов с потоками и оценка ассертов) и, по запросу, cleanup-plan.md (конкретный план удалений). Проект хранит в репозитории и образцы плохих тестов с источниками — их удобно использовать как эталон при ручной проверке выводов агента.
Установка: Claude Code, Codex и standalone-вариант
Проще всего — через маркетплейс. В Claude Code это две команды:
/plugin marketplace add haukebri/mira-test-engineer
/plugin install clean-test-suite@mira-test-engineer
После установки навык вызывается как /clean-test-suite:clean-test-suite. В Codex — те же шаги в терминале:
codex plugin marketplace add haukebri/mira-test-engineer
codex plugin add clean-test-suite@mira-test-engineer
Затем нужно перезапустить сессию, доверить опциональный reminder-hook через /hooks и выбрать навык через /skills или явно попросить clean-test-suite.
/plugin marketplace add для Claude Code и codex plugin add для Codex. Реальный скриншот GitHub, снят на момент публикации.Если не хочется связываться с плагинами — навык работает и как standalone-каталог plugins/clean-test-suite/skills/clean-test-suite/, который копируется в проект. Пути установки для разных хостов:
| Хост | Проектный путь | Личный путь | Вызов в агенте |
|---|---|---|---|
| Claude Code | .claude/skills/clean-test-suite/ |
~/.claude/skills/clean-test-suite/ |
/clean-test-suite |
| Codex | .agents/skills/clean-test-suite/ |
~/.agents/skills/clean-test-suite/ |
$clean-test-suite |
| Pi | .pi/skills/clean-test-suite/ |
~/.pi/agent/skills/clean-test-suite/ |
/skill:clean-test-suite |
| DeepSeek Harness | .dsh/skills/clean-test-suite/ |
общий .agents/skills/ |
попросить загрузить навык |
Pi и DeepSeek Harness используют нативные прогрессивные загрузчики скиллов — подтягивают тело навыка, когда задача совпадает, а не держат его в контексте постоянно. Для Codex, Pi и dsh есть общая деталь: все три умеют читать проектный .agents/skills/, поэтому достаточно одной установки.
Запуск ревью и одобрение чистки
Полный цикл — это два промпта, и они разведены по разным шагам сознательно. Первый — ревью без единого изменения:
Review this project's test suite using clean-test-suite.
Write the project model, audit, and proposed cleanup plan.
Do not change tests or production code.
Агент читает код, строит project-model.md, пишет test-audit.md и предлагает удаления в cleanup-plan.md, ничего не трогая. Дальше человек читает, какие потери защиты названы в плане, и одобряет точный список:
Apply the cleanup plan in .test-review/cleanup-plan.md.
I accept its named protection losses.
Do not write replacement tests or change production code.
Ключевые ограничения зашиты в сам навык, и их стоит повторять при работе с любым агентом:
- Удаление идёт первым. Замена удалённого — отдельная, опциональная работа.
- Меньший набор — не заявление о полном покрытии. В отчёте о пробелах говорится честно, что не защищено.
- Реальные дефекты продукта — не повод удалять валидные тесты. Навык может предложить чистку только по запросу, а не после каждой правки кода.
- Одобрение — это контроль на уровне инструкции, а не техническая песочница. Диффы надо смотреть, изменения держать восстанавливаемыми.
В README предлагают перед первой чисткой проверить установку отдельным промптом: попросить агента назвать пути к SKILL.md и референсам, сказать, куда ложатся отчёты и какое одобрение нужно перед удалением. Если агент не находит референсы или не требует одобрения — установка неполная, чинить надо её, а не запускать чистку.
Write Good Tests: политика, а не разовая уборка
Второй навык — про то, чтобы набор не зарос снова. Перед добавлением теста он требует оправдать его защиту: что именно тест охраняет и почему это важное поведение, а не копия текста или внутренняя деталь реализации. Во время код-ревью он отсекает вводящие в заблуждение тесты и показывает важные пробелы — но без требования теста на каждую правку.
Механика напоминаний у Claude Code и Codex — однострочный reminder, который срабатывает на старте сессии, перед отправкой промпта пользователя и перед запуском сабагента: «подгрузи навык Write Good Tests перед тестовой работой или код-ревью». Само тело политики в контекст не впрыскивается, а подгружается, только когда задача совпала.
Показательная деталь из README Write Good Tests: корректный результат политики — отсутствие нового теста. Если изменение не требует защиты, агент должен сказать «тест не нужен», а не выдумать кейс, чтобы показать работу. Для команды это смена привычки: ценность агента измеряется не числом написанных тестов, а числом не написанных впустую.
Как не переборщить: границы чистки
Сокращение тестов агентом — операция с риском в обе стороны. Слишком мягко — остаётся мусор, слишком агрессивно — теряется защита.
- Удаление не равно отказу от покрытия. Сначала вырезается то, что не защищает; важные пробелы из отчёта закрываются отдельным проходом, но не пересозданием всего, что удалено.
- Нужен отчёт о пробелах.
test-audit.mdфиксирует, какие потоки не покрыты, — иначе «почистили» превращается в «потеряли». - Замена — опциональная отдельная работа. Один проход чистит, второй — закрывает пробелы. Совмещать опасно: в одном заходе агент легко удаляет тест и тут же пишет похожий, только хуже.
- Человек утверждает потери. В плане названо, какая частичная защита пропадает, — это сознательное решение, а не побочный эффект.
Отдельно про качество: навыки, которые режут плохие тесты, не отменяют ревью ассертов. «Тест должен уметь упасть, когда поведение ломается» — критерий, который стоит применять вручную к каждому сомнительному кейсу, даже если агент его пропустил.
Чек-лист внедрения
- Поставьте навык в проект через маркетплейс или скопируйте standalone-каталог в
.claude/skills/(или.agents/skills/для Codex). - Проверьте установку отдельным промптом: пути к референсам, куда идут отчёты, какое одобрение нужно.
- Прогоните ревью без изменений на disposable-worktree, посмотрите
test-audit.mdиcleanup-plan.md. - Одобрите точный план, примените и запустите выживший набор.
- Подключите Write Good Tests, чтобы новые тесты не вернули мусор: напоминание перед тестовой работой и код-ревью.
- Зафиксируйте критерий в AGENTS-файле проекта: тест добавляется, только если защищает важное поведение или хрупкий путь.
Российские реалии
Сам проект доступен из России без ограничений: это открытый репозиторий на GitHub (MIT), а навыки — обычные Markdown-файлы, которые ставятся локально в проект. Для работы не нужны ни облачные аккаунты, ни зарубежная оплата — только кодинг-агент с моделью, которая уже у вас настроена.
Ограничение другое: навыки рассчитаны на агентов с чтением и редактированием файлов и доступом к терминалу. Для Claude Code и Codex из России это означает обычный набор сложностей — сервисы не работают с российского IP без VPN, оплата российскими картами невозможна, реальный путь через зарубежную карту, посредников или крипту (разбор geo-ограничений Anthropic — на Habr, июнь 2026; практика работы через VPN и посредников с оценкой рисков — в кейсе на spryt.ru). Если это не устраивает, остаются локальные скиллы с доступными в РФ моделями и хостами — например, standalone-путь с открытым инструментом, работающим через API, доступный из России.
Русскоязычного опыта именно по агентской чистке тестовых наборов на момент публикации не нашлось — ни на Habr, ни на vc.ru, ни в профильных Telegram-каналах тема «агент удаляет бесполезные тесты» ещё не осмыслена. Ближе всего статьи про генерацию тестов агентами, но угол там противоположный. Если будете внедрять — вероятно, вы окажетесь одним из первых, кто опишет результат на русском.
Честные ограничения
- Проект молодой и маленький. В репозитории два звёздочных форка и свежие коммиты; сам автор в README пишет, что «документированные пути интеграции — не заявление, что каждый хост и версия прошли живое end-to-end-тестирование». Перед продом проверяйте на своём стеке.
- Навык не гарантирует качество решений. Автор прямо предупреждает: «успешная загрузка навыка не устанавливает качество решений модели». Оценка ассертов зависит от модели, которая его исполняет.
- Напоминания не гарантируют послушание. Hook добавляет одну фразу, но модель может её проигнорировать; родительский процесс не покрывает независимо запущенные CLI-процессы.
- Одобрение — ручная работа. План удалений надо читать и проверять. Это убирает автоматизацию «в один клик», и это осознанный выбор авторов.
- Чистка не заменит архитектуру тестов. Скилл вырезает мусор, но не спроектирует тестовую стратегию для легаси без тестов — для этого нужен отдельный проход, который закрывает пробелы из отчёта.
Вывод
Проблема AI-тестов не в том, что их слишком мало. Агент штампует сотни кейсов, потому что генерация бесплатна, а «тесты добавлены, серия зелёная» — лёгкая метрика для оптимизации. Mira Test Engineer предлагает обратный ход: агент, который сначала понимает код, потом оценивает, что тесты реально защищают, и удаляет остальное — с одобрением человека и отчётом о потерях.
Для практики достаточно начать с двух промптов из этой статьи: «прочитай и предложи план, ничего не меняй» и «примени план, потери принимаю». Параллельно с первой чисткой стоит включить Write Good Tests, иначе набор зарастёт снова. Критерий простой и проверяемый: тест, который не может упасть, когда поведение ломается, — не тест, а расходы на сопровождение.
По теме: AI-агент пишет тесты: pytest, Playwright и integration-тесты, что такое агентный кодинг, ИИ в терминале: кодинг-агенты, контекст Claude Code: как управлять памятью агента, Claude Code через API.
Соседняя статья недели — кейсе «user-guide-driven development».
