Лучшая идея нового агента модульных тестов для .NET не в написании тестов

Любой агент для написания кода охотно сгенерирует модульные тесты. Проблема не в отказе, а в том, что у вас оказывается 40 зелёных тестов с Assert.NotNull(result), которые продолжат проходить, даже если удалить тело метода. 2026-07-31 Amaury Levé опубликовал статью From generated code to trusted code with a unit-test agent и выпустил плагин dotnet-test в dotnet/skills. Он нацелен именно на эту проблему, и его механизм стоит позаимствовать, даже если вы никогда его не установите.

Установка занимает две строки

Плагин распространяется через маркетплейс GitHub Copilot CLI, тем же путём, на который агент modernize-dotnet перешёл в начале июля:

/plugin marketplace add dotnet/skills
/plugin install dotnet-test@dotnet-agent-skills

Несмотря на расположение в dotnet/, агент полиглотный: .NET, Python, TypeScript, JavaScript, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell и C++. Он ограничивается только модульными тестами, изолируя тестируемый код и подменяя внешние сервисы. Никаких интеграционных, e2e и нагрузочных тестов.

Проверка, которая выполняется до отчёта об успехе

Внутри code-testing-generator представляет собой внутренний оркестратор (user-invocable: false), распределяющий работу по цепочке субагентов: researcher, planner, implementer, builder, tester, fixer и linter. Он выбирает один из трёх путей в зависимости от объёма задачи, и рекомендация приятно консервативна: большинство запросов должны идти по пути Direct и полностью пропускать конвейер, а полные циклы Research, Plan и Implement остаются для случаев, когда работа затрагивает не связанные между собой файлы исходного кода.

Важно то, что происходит до момента, когда агенту разрешено завершить работу. Для любого нетривиального дополнения (примерно пять тестов и больше либо перечисленный список вариантов поведения) обязательна предварительная проверка из трёх шагов:

1. Анализ псевдомутаций через skill test-gap-analysis: действительно ли эти утверждения упадут, если изменится реализация?
2. Проверка глубины утверждений через assertion-quality: не являются ли утверждения слабыми, отсутствующими или тавтологичными?
3. Сопоставление промпта и сценариев: у каждого запрошенного варианта поведения есть выделенный тест, а не случайное покрытие?

Именно в этом разница между тестом, который принимает компилятор, и тестом, который заслуживает своего места:

// Fails the assertion-quality check: green even if Apply() returns input unchanged
Assert.NotNull(cart.Apply(coupon));

// Survives pseudo-mutation: pins the actual behavior
var result = cart.Apply(coupon);
Assert.Equal(90.00m, result.Total);
Assert.Single(result.AppliedDiscounts, d => d.Code == "SAVE10");

Только после этого выполняется сборка всего workspace, прогон полного набора тестов и проверка того, что механизм обнаружения тестов самого репозитория находит новые файлы.

Что говорят цифры

Microsoft сообщает о доле выполненных задач 92.1% (140 из 152) против 78.9% у Copilot без агента, причём разрыв растёт на расплывчатых промптах: 88.8% против 66.3%. Среднее время задачи составило 359 секунд при покрытии 72.4% строк и 49.8% ветвей.

Цифру по ветвям стоит читать честно. Половина ветвей остаётся без покрытия, и это примерно то, чего ждёшь от агента, который останавливается при закрытии своего чек-листа, а не при достижении цели по покрытию. Ценность здесь не в том, что он заменяет вас в написании тестов. Ценность в том, что проверка мутаций и утверждений даёт формализованный ответ на вопрос “как понять, что сгенерированный тест стоит сохранить”, и эту идею можно перенести в любой агент, которым вы уже пользуетесь.