Support testing Aspire-orchestrated services

[captainsafia]

While working on implementing functional tests in big eShop, the requirement to run service dependencies under test came up. For example, functional tests for the Catalog API require that a Postgres database is instantiated.

In Aspire. we currently achieve this by implementing a test fixture that launches an Aspire app host with a Postgres resource and passing the connection string of the instantiated database resource to the service's host.

While this strategy works, there's a few noticeable drawbacks:

• DCP makes assumptions about how the Aspire host is instantiated, in particular requiring that the Aspire orchestrator is executing the app host. See https://github.com/dotnet-architecture/eShop/pull/218 for more info.
• We need to configure an entire app host when in reality we want to launch a collection of resources independent of it, a model similar to test containers.

How should we think about providing an integration testing experience for developers building Aspire-orchestrated services?

[captainsafia]

This is pretty close but:

DCP makes assumptions about how the Aspire host is instantiated, in particular requiring that the Aspire orchestrator is executing the app host. See https://github.com/dotnet-architecture/eShop/pull/218 for more info.

Is the last remaining pickle. In the Aspire 💚 Testing chat, we discussed a possible solution to this which is adding a new DistributedApplicationOptions.AssemblyName options to support overriding how the DCP lookup happens.

cc: @danegsta @davidfowl

[davidfowl]

@captainsafia can close this one?

[danegsta]

This should be resolved by the new AssemblyName option and temp path changes. Please re-open if there are further issues that are still blocking test scenarios.