How to configure AppHost for integration tests?

[impworks]

I have an application that uses PostgreSQL.
When I am developing it locally, I use WithDataVolume to store data between sessions.
In the integration tests, however, I need to start with an empty volume each time to ensure test isolation.
Right now I am using the console app arguments to pass a special flag:

Integration Test:

var appHost = await DistributedApplicationTestingBuilder.CreateAsync<Projects.MyApp_AspireHost>(["--integration-test"]);

AppHost/Program.cs:

var builder = DistributedApplication.CreateBuilder(args);
var isIntegrationTest = args.Any(x => x == "--integration-test");
var pgsql = builder.AddPostgres("postgres");

if(!isIntegrationTest)
    pgsql.WithDataVolume();

var db = pgsql.AddDatabase("mydb");

This approach works, but feels like a dirty hack to me, which may have downsides or consequences of which I am not aware.
Is there a proper way to achieve this?

[davidfowl]

@ReubenBond should we set a first class flag for when the application has been booted with the DistributedApplicationTestingBuilder? I've seen this a couple of times.

cc @mitchdenny

[impworks]

This is not just about the volume persistence. When designing an official solution, please make it generic enough to accomodate cases when there have to be arbitrary cluster configuration differences between the actual set-up and the integration tests. A couple of examples from my particular configuration:

• RabbitMQ: local docker image for tests, vendor-hosted SaaS solution for production
• PostgreSQL: regular docker image for tests, custom docker image with auto-upgrade for development, vendor-hosted solution for production
• Some of the services should ONLY be started in the integration tests run (e.g. mocks of 3rd party APIs)
• Some of the services should NOT be started in the integration tests run (e.g. npm-based front-end apps, to save time and resources on the build pipeline)

[mitchdenny]

@impworks we do actually support the concept of customizing resources for deployment. Postgres is a good example:

var db = builder.AddPostgres("pg")
                .PublishAsAzurePostgresFlexibleServer()

For local development we'll use Postgres in a docker container locally, but if you deployed to say Azure using azd then we'd deploy using the Azure-managed service. Its possible to extend the model for other cloud providers as well (AWS is already working on their extensions).

[davidfowl]

I think the meta point here is that we need to set something to indicate that we're running from a test and that developers can use in their app host to write conditional logic (like we have for publish and run).

[KennethHoff]

Why not just do that; add a third option, "publish", "run", "test"

[davidfowl]

We could.