Aspire Integration Testing
Overview
Integration tests for .NET Aspire distributed applications. Validates service startup, health endpoints, cross-component communication, and observability.
REQUIRED: superpowers:test-driven-development, superpowers:verification-before-completion
When to Use
- Repository includes .NET Aspire AppHost
- Distributed application with multiple services
- Cross-component behavior validation needed
- Opt-out: User explicitly refuses testing
Detection and Deference
Before creating Aspire integration tests, check for existing patterns:
Existing Tests Detection
| Pattern | Detection Command | If Found |
|---|---|---|
| AppHost Tests | find . -name "*.AppHost.Tests.csproj" |
Enhance existing |
| Aspire.Hosting.Testing | grep -r "Aspire.Hosting.Testing" *.csproj |
Use existing project |
| Test strategy doc | test -f docs/testing-strategy.md |
Reference existing |
Deference Rules
When existing Aspire tests are detected:
- Existing test project: Add new tests to existing project.
- Existing strategy doc: Update rather than duplicate.
- Partial coverage: Add tests for uncovered components only.
Only create new test project when detection finds nothing.
Decision Capture
Testing decisions must be captured:
- Testing Strategy: Update
docs/testing-strategy.mdwith Aspire testing approach - Test Project README: Document what each test validates
- ADR (optional): For complex multi-component testing decisions
Testing Strategy Template
Add to docs/testing-strategy.md:
## Aspire Integration Testing
### Scope
- All AppHost-managed services tested
- Health and alive endpoints validated
- Cross-component flows verified
### Test Categories
1. **Startup Tests:** Application starts, all services healthy
2. **Health Tests:** /health and /alive endpoints
3. **Integration Tests:** Cross-component communication
4. **Observability Tests:** Logging, tracing correlation
Core Workflow
- Opt-out check: User refused testing? Document in
docs/exclusions.md - Identify components: APIs, workers, databases, queues, caches
- Create test project: Reference Aspire.Hosting.Testing
- Mandatory tests:
- Application starts successfully
/healthendpoint for all services (200 OK)/aliveendpoint for all services (200 OK)- Resource connectivity (database, queue connections)
- Cross-component flows: API → queue → worker, API → database
- Observability: Structured logging, correlation IDs
- Document: Test strategy in
tests/README.md
See Testing Patterns and API Reference.
Reference Templates
Use pre-built templates to accelerate Aspire test setup:
| Template | Use Case |
|---|---|
| templates/aspire-integration-tests.cs.template | Basic Aspire test class |
| templates/aspire-test-project.csproj.template | Test project configuration |
Using Templates
- Copy templates to
tests/{Project}.AppHost.Tests/ - Replace
{NAMESPACE}with your root namespace - Replace
{AppHostProject}with your AppHost project name - Add reference to your AppHost project
- Run
dotnet testto verify setup
Rationalizations Table
| Excuse | Reality |
|---|---|
| "Aspire handles health checks" | Health checks exist but must be validated. Services can fail silently. |
| "Too complex to test" | Aspire.Hosting.Testing makes it straightforward. 20 min setup. |
| "Can test in staging" | Local testing is 10x faster. Staging debugging wastes hours. |
| "Demo doesn't need tests" | Demos become production. Start right or rewrite. |
| "Manual verification is enough" | Manual tests don't catch regression. Automated tests do. |
Red Flags - STOP
- "Aspire infrastructure just works"
- "Too complex to test distributed systems"
- "Can verify in staging/production"
- "Dashboard shows green"
- "Will add tests later"
All mean: Apply skill or document explicit opt-out.