aspire-integration-testing_skill

This skill helps you write end-to-end integration tests for .NET Aspire apps using xUnit, real dependencies, and dynamic endpoint discovery.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational