Generate unit tests.<\/p>\n<\/blockquote>\n
That request leaves important questions open. Which code needs tests? Which
\ntest framework does the project use? Where should the tests go? How does the
\nbuild find them? What should the tests check?<\/p>\n
The agent can learn from the repository, write the tests, and prove that they
\nwork.<\/p>\n
This is why we built The agent writes unit tests<\/strong>. It isolates the code under test and mocks Integration, end-to-end, browser, and performance tests are outside its current It does more than make the tests pass. It checks the assertions, the requested The agent does not start writing tests immediately. It learns from the The agent searches the repository for the code that needs tests. It detects the It also finds the correct commands to build and run the tests.<\/p>\n This prevents a common problem. A new test project can build and pass on its A single method does not need a large plan. A whole solution does.<\/p>\n The agent chooses from three paths:<\/p>\n For larger tasks, the agent lists the code that needs tests. It starts with The plan follows the request. A request for one module should not change every The agent follows the local conventions and runs the tests as it works. If the It does not change production code during test generation. It also avoids unit A test can pass but provide little or no added value. For example, it may only The agent checks for these problems before it finishes:<\/p>\n This workflow turns a short prompt into a tested result.<\/p>\n In our latest benchmark, the agent completed 140 of 152 tasks. Stock Copilot, The biggest gains came from prompts like the one at the start of this post. We Vague prompts produced the clearest result. The agent passed 79 of 89 tasks, We used our internal unit-testing benchmark. It contains 152 tasks from real We compared four setups: stock GitHub Copilot, stock Claude Code, our agent in A task passed only when:<\/p>\n The full breakdown shows that detailed prompts were tied:<\/p>\n
\ncode-testing-generator<\/code><\/a>.
\nIt is an open-source, polyglot agent for unit-test generation. You can find it
\nin the
\ndotnet-test<\/code> plugin<\/a>
\nin dotnet\/skills<\/code><\/a>.<\/p>\n
\nexternal services and other outside dependencies.<\/p>\n
\nscope.<\/p>\n
\nscenarios, and whether the repository\u2019s normal test run finds the new tests.<\/p>\nWhat happens after the prompt<\/h2>\n
\nrepository first, then plans, writes, and checks the tests.<\/p>\n![\"Workflow](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/unit-testing-agent-workflow.png\")
<\/p>\nFirst, learn from the repository<\/h3>\n
\nlanguage and test framework. It also looks for existing tests that show where
\nnew tests belong and how they should look.<\/p>\n
\nown but never run in continuous integration (CI) because it was not added to
\nthe solution or the repository\u2019s test command. The agent checks how the
\nrepository discovers tests and confirms that the new tests appear there.<\/p>\nNext, choose the right amount of work<\/h3>\n
\n
\ngoal.<\/li>\n<\/ul>\nThen, plan and write the tests<\/h3>\n
\nsimple code and then moves to code with more dependencies. It maps each
\nbehavior to a test file.<\/p>\n
\ntest project in the repository.<\/p>\n
\ngenerated code does not compile, it fixes it. If an assertion is wrong, it
\nreads the source and corrects the test.<\/p>\n
\ntests that call external URLs, open ports, or depend on exact timing.<\/p>\nFinally, check that the tests are useful<\/h3>\n
\ncheck that a result is not null. It may test the wrong method. It may even pass
\nif the method always returns a default value.<\/p>\n\n
\nlightweight form of mutation testing.<\/li>\nWhat we measured<\/h2>\n
\nwhich used the same tool without our plugin, completed 120 with the same model.
\nThat is a 92.1% completion rate versus 78.9%<\/strong>, with 63% fewer failures.<\/p>\n
\ncall these vague prompts<\/strong> because they leave most decisions to the agent.<\/p>\nVague prompts show why the workflow matters<\/h3>\n
\ncompared with 59 for stock Copilot. Failures fell from 30 to 10.<\/p>\n
\nrepositories. Some prompts are detailed. Others are vague and leave most
\ndecisions to the agent.<\/p>\n
\nGitHub Copilot, and our agent in Claude Code. The results below focus on the
\nGitHub Copilot comparison unless we say otherwise. Both Copilot setups used the
\nsame model and prompts.<\/p>\n\n
![\"Specialized](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/vague-prompt-results.png\")
<\/p>\n![\"Paired](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/paired-benchmark-outcomes.png\")
<\/p>\n![\"C#](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/csharp-failures-by-model.png\")
<\/p>\n