Launch, Test, Teardown: Hands-On testing with .NET Aspire

Your application depends Databases, message brokers, external APIs. To test your application in full these all need to be available. Creating and environment for development, CI, or other testing can be difficult, leading to brittle startup scripts and failures that are hard to reproduce. But with Aspire you can build stable and trustworthy environments.

In this workshop, you'll learn how to use .NET Aspire as a test harness. Using an application with a frontend, API, database, and external services. We'll start by adding the AppHost and piece by piece build on top of it.

You'll learn to:
- setup databases, message queues and how to deal with data
- mock 3rd party APIs
- connect AI for discovery and analysis
- run integration tests (with or without BDD and Playwright)
- customize Aspire to your needs
- hook this into you CI/CD pipeline

I'll provide an example application to work with. But feel free to bring you own application as extra challenge!

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.

Taming Integration Tests with .NET Aspire

Your application depends Databases, message brokers, external APIs. To test your application in full these all need to be available. Creating and environment for development, CI, or other testing can be difficult, leading to brittle startup scripts and failures that are hard to reproduce. But with Aspire you can build stable and trustworthy environments.

In this session, I'll demonstrate how I use .NET Aspire as a test harness. Using an application with a frontend, API, database, and external services. We'll launch the system, execute tests, and tear it down again. I'll share the good stuff and the things to avoid. The demos include scenarios showcasing BDD, observability, debugging, database management, playwright, pipeline integration, and how AI can use this setup as well.

You will leave with a practical example and some inspiration on to you Aspire for use across development and testing.

.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.