- Home
- Skills
- Kevintsengtw
- Dotnet Testing Agent Skills
- Dotnet Testing Advanced Aspire Testing
dotnet-testing-advanced-aspire-testing_skill
- C#
19
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill kevintsengtw/dotnet-testing-agent-skills --skill dotnet-testing-advanced-aspire-testing- SKILL.md10.5 KB
Overview
This skill is a practical guide for building advanced integration tests with .NET Aspire Testing for distributed .NET applications. It covers AppHost-based test environments, container lifecycle management, multi-service orchestration, Respawn configuration, and time-testability design. Use it to migrate from Testcontainers to Aspire Testing or establish repeatable cloud-native integration test suites.
How this skill works
The skill inspects and documents how to declare an AppHost project to represent your full application topology and then use DistributedApplicationTestingBuilder to spin up real containers for services like PostgreSQL and Redis. It explains container lifetime modes, readiness checks, explicit database initialization, and how to wire Respawn for reliable state reset. It also shows how to reuse an AspireAppFixture via xUnit collection fixtures and how to make time-dependent code testable with TimeProvider.
When to use it
- You need integration tests that run full multi-service stacks (DB, cache, APIs) with real containers.
- You are migrating tests from Testcontainers to a declarative Aspire AppHost approach.
- You want automatic container lifecycle management and session-scoped cleanup.
- You need consistent, repeatable test isolation using Respawn for PostgreSQL.
- You require testing of inter-service interactions in cloud-native .NET apps.
Best practices
- Create an AppHost project that declares all services and references your API project for accurate orchestration.
- Use ContainerLifetime.Session for test sessions to ensure automatic cleanup and avoid resource leak.
- Implement explicit readiness checks (retry loop) for services before running tests to avoid flakiness.
- Initialize or create databases manually after container start because Aspire does not auto-create DBs.
- Use xUnit CollectionFixture (AspireAppFixture) to start containers once per test collection and share across tests.
- Abstract system time with TimeProvider to make time-dependent behaviors deterministic in tests.
Example use cases
- Integration tests for an Aspire-hosted Web API that depends on PostgreSQL and Redis.
- Migrating an existing Testcontainers-based test suite to a declarative Aspire AppHost approach.
- End-to-end contract tests that verify workflows across multiple microservices running in containers.
- CI jobs that need fast, isolated test sessions with automatic cleanup of containers and resources.
- Resetting database state between tests using Respawn configured for PostgreSQL.
FAQ
Yes. Aspire Testing uses real containers, so Docker (Desktop/engine) is required to run the service containers.
Can Aspire create databases for me?
No. Aspire starts database containers but does not auto-create named databases; add a small initialization step to create DBs as needed.
When should I prefer Testcontainers over Aspire Testing?
Choose Testcontainers for fine-grained container control, mixed-language stacks, or when your project is not built on Aspire.