We don't need no stinkin' testers

A world without testers, how great would that be? Just type your C# code, build things, deliver things without someone else nagging about bugs and quality.
It would suck. But for different reasons than you would think! We need their thinking before coding starts, not afterwards.

I have worked on software where problems were discovered only after implementation is done or were not discovered at all. To get earlier feedback, we introduced testing techniques that developers and testers could use before and during development, with automated checks and becoming part of CI/CD.

In this demo-driven session, I'll show the practices we introduced and how they help expose risks earlier. Pratices and tools like example mapping, approval testing and Playwright & Aspire wroking in a integrated test. The goal is not to replace testers with automation, but to bring their expertise into software design while giving developers more responsibility for quality.

The technical changes worked, but their adoption was slower than I expected. I'll discuss why introducing a useful testing technique does not mean that people will immediately use it, what got in the way, and what I would do differently. Despite those challenges, the resulting feedback made the software safer to release.

Attendees will leave with practical techniques like example mapping, guidance for choosing where different kinds of tests belong, and lessons for introducing those practices without overestimating their adoption.

This session is intended for C# developers, QA and test-automation engineers, and technical leads who want test expertise to influence software before defects reach production.

AI writes the code, Roslyn guards the rules

Coding agents can implement a feature quickly, but they can also satisfy a complexity warning with a worse refactoring or cross an architectural boundary documented only in prose. Better prompts help, but they do not provide deterministic enforcement.

In this session, I'll demonstrate a feedback loop I use in day-to-day .NET development: Roslyn analyzers detect violations, and a GitHub Copilot hook adds rule-specific remediation guidance, and the build refuses to accept the change until the diagnostics are resolved.

We'll examine two implementation cases. First, an agent "fixes" a maintainability warning while making the design worse. We'll improve the analyzer feedback so that it produces a useful refactoring instead of merely satisfying the metric. Next, we'll use a custom analyzer to enforce the permitted dependency directions in a Clean Architecture-style solution, preventing domain and application code from referencing infrastructure implementations.

Along the way, I'll show how diagnostics reach the agent, how the analyzers and their guidance are tested, and what happens when the agent cannot find a valid solution. We'll look at practical escape routes: retrying with a more capable model, improving the remediation guidance, or treating selected diagnostics as warnings rather than blocking the build.

This session is for .NET developers, architects, and technical leads who use coding agents and want enforceable engineering constraints instead of relying exclusively on prompts and documentation.

Attendees will learn how to:
- Turn Roslyn diagnostics into an enforced agent feedback loop.
- Add contextual remediation guidance that discourages metric gaming.
- Implement and test an analyzer for an architectural boundary.
- Combine analyzers, agent instructions, build gates, and human review.

.NET Aspire as a Test Harness: From Local Development to CI

Your application depends on more than its own code. Databases, message brokers, external APIs, and similar dependencies must be available before you can test your application in full. Recreating that environment separately for local development, CI, and other testing contexts can be difficult, leading to brittle startup scripts and failures that are hard to reproduce. How nice would it be to have a single source of truth for setting everything up so that you can easily test your application?

In this session, I'll demonstrate how to use a .NET Aspire AppHost as a test harness. Using an application with a frontend, API, database, and external service, we will launch the system, execute tests, and tear it down again. You'll learn what I found valuable and where using Aspire as a test harness works best. You'll also learn about the drawbacks and things to avoid. The demos include scenarios showcasing BDD, observability, debugging, database management, playwright, pipeline integration, and how AI can hook into this setup.

You will leave with a practical example of how to either reuse your Aspire AppHost or build a new one for use across development and testing. The example uses several tools, including xUnit, Reqnroll, Playwright, and, of course, Aspire. After the talk, the code will be available!

.NET developers who build applications with external dependencies and want a consistent approach to full-stack testing across local development and CI. Basic familiarity with .NET Aspire and automated testing is helpful but not required.