- Home
- Skills
- Aaronontheweb
- Dotnet Skills
- Aspire Integration Testing
aspire-integration-testing_skill
- Shell
643
GitHub Stars
3
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 aaronontheweb/dotnet-skills --skill aspire-integration-testing- advanced-patterns.md12.4 KB
- ci-and-tooling.md5.0 KB
- SKILL.md9.4 KB
Overview
This skill teaches how to write robust integration tests for .NET Aspire applications using xUnit. It focuses on testing ASP.NET Core apps with real dependencies, reliable fixture lifecycles, dynamic endpoint discovery, and patterns for distributed systems. The guidance emphasizes using real infrastructure (databases, caches, message queues) orchestrated by Aspire to surface realistic issues early.
How this skill works
Tests use an IAsyncLifetime fixture that builds and starts a DistributedApplication via Aspire testing APIs. The fixture waits for health checks, exposes discovered endpoints and connection strings, and provides helper methods to create HttpClient instances. Tests run against services in containers with dynamic ports, while environment overrides configure test-specific behavior. File-watcher and parallelization fixes are applied to avoid flaky or resource-exhausting runs.
When to use it
- Writing integration tests for Aspire-based applications
- Testing ASP.NET Core apps with real database or cache dependencies
- Verifying service-to-service communication in distributed systems
- Running UI tests with Playwright against Aspire-orchestrated services
- Testing microservices with realistic networking and discovery
Best practices
- Use real dependencies instead of mocking core infrastructure to catch integration issues
- Let Aspire assign dynamic ports; discover endpoint URLs at runtime, don’t hard-code them
- Implement IAsyncLifetime fixtures for deterministic startup and teardown
- Disable host file-watchers in tests to avoid inotify exhaustion on Linux
- Control test parallelism with xUnit collections to maintain isolation
- Wait for health checks or resource notifications before executing assertions
Example use cases
- Start a distributed app in a fixture, create HttpClient from discovered endpoint, assert API health and behavior
- Run database integration tests that obtain a connection string from Aspire and validate migrations/data
- Combine Aspire fixtures with Playwright to load the web UI and assert page content or navigation
- Test service-to-service calls inside the distributed app by discovering internal endpoints and issuing requests
- Configure AppHost to enable test-only auth and fake external services for isolated end-to-end tests
FAQ
Set DOTNET_HOSTBUILDER__RELOADCONFIGONCHANGE=false early via a ModuleInitializer in the test project to disable config file watching for all test hosts.
How do I get an HTTP URL for a resource started by Aspire?
Use the DistributedApplication API to get a resource and call GetEndpoint or a helper like GetEndpointUrl; endpoints are discovered at runtime and include dynamic ports.