A few months ago, we introduced a new guided agentic workflow in the Visual Studio Debugger Agent designed to help you move from a bug report to a verified fix without spending your morning guessing where to begin.
If you missed that announcement, check out Stop Hunting Bugs: Meet the New Visual Studio Debugger Agent to see how the Agent builds a hypothesis, guides the debugger, investigates your application at runtime, and validates the final change.
Today, we’re building on that experience with a new Test-Driven Investigation workflow. The Debugger Agent can now create or identify a focused test, debug through it to investigate the root cause, and rerun it to validate the fix. It’s especially useful for the bug reports we all know too well: an exception, a stack trace, or a note that something “sometimes fails,” with no dependable way to reproduce it manually.
Building on the Guided Debugger Loop
Live debugging remains a great fit when a problem can be reproduced reliably. When it can’t, Test-Driven Investigation gives the Debugger Agent another way in: capture the failure in an automated test and make it repeatable.
Start with a GitHub issue, Azure DevOps work item, or a simple issue description. (See example prompts ) The Agent reviews the available context, asks for missing details, and recommends the best investigation path.
Choosing the Right Path for the Problem
When reliable reproduction steps are available, the Debugger Agent can help you choose the approach that best fits the scenario:
- Live Debugging: Launch the application, reproduce the issue interactively, and inspect the live runtime state.
- Test-Driven Investigation: Create or identify a test that reproduces the behavior, then use that test to drive the investigation and validate the fix. (Existing Test infrastructure is needed)
If the issue doesn’t include usable reproduction steps, the Agent first looks for a practical way to derive them from the description, diagnostics, and code context. If it can’t establish a dependable manual repro and finds supported test infrastructure, it automatically starts the Test-Driven Investigation workflow and generates or identifies a focused test.
A Failing Test Becomes the Investigation
Once a test captures the problem, the Debugger Agent doesn’t simply generate code and hope for the best. It debugs through the test, using breakpoints and runtime information to understand why the behavior occurs.
The workflow can help you:
- Reproduce the issue consistently. The same failing test can be run throughout the investigation.
- Inspect what the code is actually doing. The Agent evaluates variables, call stacks, and runtime state while the test executes.
- Test the hypothesis. Potential causes can be confirmed or ruled out using evidence from the debugging session.
- Validate the resolution. After you approve the proposed change, the Agent reruns the test to confirm that it passes.
- Check for regressions. When appropriate, related tests can also be run to make sure the fix hasn’t disrupted existing behavior.
This creates a useful debugging loop: reproduce, investigate, fix, and verify. Instead of relying on a one-time manual check, you finish with an automated test that documents the expected behavior and can continue protecting it in the future.
You’re Still Driving
You stay in control throughout the workflow. Review or modify the test, steer the investigation, and approve the fix helping ensure the test reflects the real customer problem.
Try It and Let Us Know What You Think!
Try Test-Driven Investigation with your next hard-to-reproduce bug. We’d love to hear how it fits into your debugging workflow and what you’d like to see next.
Stay connected with the Visual Studio team by following @VS_Debugger, @VisualStudio, YouTube, and LinkedIn.
Would be possible, maybe in the future create or deduced the test driven investigation starting from a post mortem dump? In that case many information could be already deduced (like already done today for the ) but sometimes the crash is difficult to reproduce. This could help in extending tests all over the huge legacy codebases that have a very low code coverage.