Generate unit tests.<\/p><\/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\n The agent writes unit tests<\/strong>. It isolates the code under test and mocks\nexternal services and other outside dependencies.<\/p>\n Integration, end-to-end, browser, and performance tests are outside its current\nscope.<\/p>\n It does more than make the tests pass. It checks the assertions, the requested\nscenarios, and whether the repository’s normal test run finds the new tests.<\/p>\n The agent does not start writing tests immediately. It learns from the\nrepository first, then plans, writes, and checks the tests.<\/p>\n The agent searches the repository for the code that needs tests. It detects the\nlanguage and test framework. It also looks for existing tests that show where\nnew tests belong and how they should look.<\/p>\n 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\nown but never run in continuous integration (CI) because it was not added to\nthe solution or the repository’s test command. The agent checks how the\nrepository discovers tests and confirms that the new tests appear there.<\/p>\n 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\nsimple code and then moves to code with more dependencies. It maps each\nbehavior to a test file.<\/p>\n The plan follows the request. A request for one module should not change every\ntest project in the repository.<\/p>\n The agent follows the local conventions and runs the tests as it works. If the\ngenerated code does not compile, it fixes it. If an assertion is wrong, it\nreads the source and corrects the test.<\/p>\n It does not change production code during test generation. It also avoids unit\ntests that call external URLs, open ports, or depend on exact timing.<\/p>\n A test can pass but provide little or no added value. For example, it may only\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 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,\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 The biggest gains came from prompts like the one at the start of this post. We\ncall these vague prompts<\/strong> because they leave most decisions to the agent.<\/p>\n Vague prompts produced the clearest result. The agent passed 79 of 89 tasks,\ncompared with 59 for stock Copilot. Failures fell from 30 to 10.<\/p>\n We used our internal unit-testing benchmark. It contains 152 tasks from real\nrepositories. Some prompts are detailed. Others are vague and leave most\ndecisions to the agent.<\/p>\n We compared four setups: stock GitHub Copilot, stock Claude Code, our agent in\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 A task passed only when:<\/p>\n The full breakdown shows that detailed prompts were tied:<\/p>\n That is 67% fewer failures<\/strong> on vague prompts. All 20 net gains came from\nthese tasks. This matches the goal of the agent: do the research that the\ndeveloper did not put in the prompt.<\/p>\n The same pattern appeared when the prompt pointed to a code change. The\nbenchmark has 15 tasks that ask for tests for a specific diff. The agent passed\nall 15. Stock Copilot passed none.<\/p>\n Both setups ran the same 152 tasks. This lets us compare each result directly.<\/p>\n The specialized agent generated 2.3% fewer tests, with effectively the same\naverage coverage. It also completed more tasks and was about 5.5% faster on\naverage. The gain came from reliability, not from producing more tests.<\/p>\n The benchmark contains 45 .NET tasks. They cover several repositories and\ndifferent task sizes. We ran the same comparison with three models:<\/p>\n The workflow helped every model. With Opus, it added eight wins with no losses.\nWith Haiku, it completed nine more C# tasks than stock Haiku.<\/p>\n The result also suggests that a strong workflow can lift a mid-tier model close\nto the best result. Across all 152 tasks, specialized GPT-5.5 reached 90.1%.\nThat was within two points of specialized Opus and more than 11 points above\nstock Opus.<\/p>\n The agent includes guidance for .NET, Python, TypeScript, JavaScript, Java, Go,\nRuby, Rust, Swift, Kotlin, PowerShell, and C++. It learns each repository’s\nconventions instead of applying C# patterns everywhere.<\/p>\n Beyond .NET, the same Opus run covered several of these languages:<\/p>\n The agent passed every Go task and more than doubled the Python completion\nrate. It also passed five Go and five Python tasks that targeted a specific\ncode change.<\/p>\n The result was not better in every language. Stock Copilot passed one more\nPowerShell task. These groups are also small, so we see them as useful signals,\nnot promises for every repository.<\/p>\n We also tested the workflow on 44 unit-test tasks from\nSWE Atlas<\/a>. This benchmark checks\nrequirements and uses code changes to see whether the tests can catch bugs.<\/p>\n The specialized agent completed four more tasks, with no stock-only wins.<\/p>\n The completion rates are much lower than in our internal benchmark. SWE Atlas\nis hard, and there is still a lot to improve.<\/p>\n The clearest gain was reliability. The agent was more likely to deliver unit\ntests that built, passed, and matched the request. The difference was largest\nwhen the prompt was vague or linked to a code change.<\/p>\n Once both setups produced a valid result, neither led every quality measure.\nStock Copilot scored slightly higher on assertions and coverage. The\nspecialized agent scored slightly higher on test hygiene, such as clean\nstructure and avoiding slow or fragile patterns.<\/p>\n These groups contain different tasks. The specialized group includes harder\ntasks that stock Copilot did not complete, so this is not a direct quality\nranking. We see these results as guidance for the next improvements: deeper\nassertions and error-path tests while keeping strong test hygiene.<\/p>\n Efficiency remained close after accounting for completed tasks. The agent used\nabout 3.2% more recorded tokens per completed task. These counts include cached\ninput, so they do not directly represent cost.<\/p>\n These results cover unit tests only. We are exploring where the same workflow\ncould help with other types of testing, but we have no committed plans to\nannounce.<\/p>\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>\nWhat happens after the prompt<\/h2>\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
Next, choose the right amount of work<\/h3>\n
\n
Then, plan and write the tests<\/h3>\n
Finally, check that the tests are useful<\/h3>\n
\n
What we measured<\/h2>\n
Vague prompts show why the workflow matters<\/h3>\n
\n
\n\n
\n \nPrompt type<\/th>\n Specialized agent<\/th>\n Stock Copilot<\/th>\n<\/tr>\n<\/thead>\n \n Vague prompts, 89 tasks<\/td>\n 79 (88.8%)<\/td>\n 59 (66.3%)<\/td>\n<\/tr>\n \n Detailed prompts, 63 tasks<\/td>\n 61 (96.8%)<\/td>\n 61 (96.8%)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n ![\"Specialized](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/vague-prompt-results.png\")
<\/p>\nMore successful results, not simply more tests<\/h3>\n
![\"Paired](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/paired-benchmark-outcomes.png\")
<\/p>\n\n
\n\n
\n \nMetric<\/th>\n Specialized agent<\/th>\n Stock Copilot<\/th>\n<\/tr>\n<\/thead>\n \n Tasks completed<\/td>\n 140\/152 (92.1%)<\/td>\n 120\/152 (78.9%)<\/td>\n<\/tr>\n \n Solutions building<\/td>\n 148<\/td>\n 145<\/td>\n<\/tr>\n \n Final test suites passing<\/td>\n 149<\/td>\n 147<\/td>\n<\/tr>\n \n Tests generated<\/td>\n 6,963<\/td>\n 7,129<\/td>\n<\/tr>\n \n Average final line coverage<\/td>\n 72.4%<\/td>\n 72.2%<\/td>\n<\/tr>\n \n Average final branch coverage<\/td>\n 49.8%<\/td>\n 49.1%<\/td>\n<\/tr>\n \n Average task time<\/td>\n 359 seconds<\/td>\n 380 seconds<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The benefit extends across models and languages<\/h3>\n
\n\n
\n \nModel<\/th>\n Specialized agent<\/th>\n Stock Copilot<\/th>\n Failure reduction<\/th>\n<\/tr>\n<\/thead>\n \n Claude Opus 4.8<\/td>\n 43\/45 (95.6%)<\/td>\n 35\/45 (77.8%)<\/td>\n 80%<\/td>\n<\/tr>\n \n GPT-5.5<\/td>\n 41\/45 (91.1%)<\/td>\n 36\/45 (80.0%)<\/td>\n 56%<\/td>\n<\/tr>\n \n Claude Haiku 4.5<\/td>\n 34\/45 (75.6%)<\/td>\n 25\/45 (55.6%)<\/td>\n 45%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n ![\"C#](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/07\/csharp-failures-by-model.png\")
<\/p>\n\n\n
\n \nLanguage<\/th>\n Specialized agent<\/th>\n Stock Copilot<\/th>\n<\/tr>\n<\/thead>\n \n Python, 15 tasks<\/td>\n 13 (86.7%)<\/td>\n 6 (40.0%)<\/td>\n<\/tr>\n \n Go, 15 tasks<\/td>\n 15 (100%)<\/td>\n 10 (66.7%)<\/td>\n<\/tr>\n \n PowerShell, 10 tasks<\/td>\n 7 (70.0%)<\/td>\n 8 (80.0%)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n A second, harder benchmark<\/h3>\n
\n\n
\n \nMetric<\/th>\n Specialized agent<\/th>\n Stock Copilot<\/th>\n<\/tr>\n<\/thead>\n \n Tasks completed<\/td>\n 16\/44 (36.4%)<\/td>\n 12\/44 (27.3%)<\/td>\n<\/tr>\n \n Wins by only one setup<\/td>\n 4<\/td>\n 0<\/td>\n<\/tr>\n \n Passing generated tests<\/td>\n 550<\/td>\n 493<\/td>\n<\/tr>\n \n Tests that caught injected bugs<\/td>\n 360<\/td>\n 316<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What we learned and what comes next<\/h2>\n
Try the agent<\/h2>\n