{"id":75162,"date":"2026-08-07T05:24:49","date_gmt":"2026-08-07T09:24:49","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=75162"},"modified":"2026-08-07T05:24:49","modified_gmt":"2026-08-07T09:24:49","slug":"microsoft-code-testing-generator","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/microsoft-code-testing-generator\/","title":{"rendered":"Microsoft Open Sources code-testing-generator, Beats Copilot 92.1%"},"content":{"rendered":"

Ask a coding assistant to “generate unit tests” and you will get a file \u2014 perhaps even a capable one \u2014 but you will not get a guarantee that it belongs in your repository, matches your team’s conventions, or will ever be discovered by your CI pipeline. That gap between producing code and proving it works is precisely what Microsoft’s newly open-sourced code-testing-generator<\/strong> agent is built to close. Released under the MIT license inside the dotnet\/skills repository<\/a>, the polyglot agent writes unit tests, executes them, and passes them through a five-stage verification gate before reporting success. On Microsoft’s internal benchmark of 152 tasks drawn from real repositories, it completed 140 \u2014 a 92.1% success rate against 78.9% for stock GitHub Copilot running on the same model and the same prompts.<\/p>\n

What is Microsoft’s code-testing-generator?<\/h2>\n

Microsoft’s code-testing-generator is an open-source, polyglot coding agent that writes unit tests and then proves they work. It is an agent definition accompanied by reusable skills, not a hosted service, so it runs inside an existing coding assistant and keeps code on the developer’s machine. It ships in the dotnet-test plugin of the MIT-licensed dotnet\/skills repository on GitHub.<\/p>\n

The agent was designed to attack a failure mode that most coding assistants<\/a> quietly accept: a prompt like “generate unit tests” does not specify which test framework to use, where the test file should live, what assertions to write, or whether the repository’s build system will even load the new file. The assistant guesses, or worse, invents a self-contained example that works in isolation but never runs in the actual project. Microsoft’s agent settles those decisions by reading the repository before it writes anything. It then plans the work, writes the tests, runs them, and subjects the results to a verification process that includes a lightweight form of mutation testing.<\/p>\n

Why “write tests” prompts fail in ordinary coding assistants<\/h2>\n

The problem is not that large language models cannot write test code. Modern assistants are more than capable of producing syntactically valid test methods in Java, Python, C#, Go, and a dozen other languages. The failure is contextual. A generated test that does not match the repository’s existing test framework is dead weight. A test that makes a network call the team has explicitly banned will be deleted in review. A test project that was never registered in the solution \u2014 the scenario Microsoft calls out specifically \u2014 builds happily on a developer’s laptop and then silently never runs in CI because nothing in the build pipeline invokes it.<\/p>\n

Stock coding assistants typically operate as stateless prompt-completion engines. They take the current file, some conversational context, and a request, and they produce an answer. They do not explore the repository, read adjacent test files to infer conventions, or verify whether the build system can see the new tests. The results can look impressive in a diff preview and still be unusable in practice. That disconnect is what separates test generation from test engineering, and it is the specific territory Microsoft’s agent is staking out.<\/p>\n

How code-testing-generator works: Research, Plan, Implement<\/h2>\n

The agent coordinates its work through a Research-Plan-Implement pipeline. Each phase is narrow and deliberate, and the pipeline is what makes the agent polyglot without requiring a bespoke implementation per language.<\/p>\n

During the research phase, the agent searches the repository for code that needs testing. It detects the programming language and the test framework already in use. It reads existing tests to extract conventions \u2014 naming patterns, assertion styles, fixture setup, file placement. Critically, it finds the real build and test commands. This last step targets a specific failure that Microsoft highlights: a test project that builds locally but never runs in CI because nothing registered it. By identifying the actual commands the repository uses, the agent ensures the tests it writes will be discoverable by the same tooling the team already runs.<\/p>\n

The plan phase maps behaviors to test files. The agent starts with straightforward code and works toward code with more dependencies, producing a concrete implementation strategy that respects the repository’s structure. The implement phase then writes the tests, runs them, fixes assertions that fail against the actual source, and repeats until the suite passes.<\/p>\n

Three execution strategies: Direct, Single Pass, Iterative<\/h3>\n

The agent selects one of three strategies depending on the scope of the request:<\/p>\n