[Enhancement]: Add `IConnectionStringProvider` for modules / container builder API

Problem

Not all Testcontainers modules represent services that can be exchanged with each other, like ADO.NET compatible modules do. However, usually (almost every time), they offer a method or property (one) that retrieves a connection string or something similar to connect to the service running inside the container.

Occasionally, developers request an additional abstraction to access the connection string of the modules' container. Currently, only ADO.NET compatible containers offer this kind of abstraction. Implementing a default connection string property or method across all modules is not accurate, as the terminologies vary depending on the actual module and service (this is one reason why modules do not offer it yet: ConnectionString, BaseAddress, Endpoint, etc.).

Apart from the absence of this abstraction, modules do not provide connection strings for container to container communication by default. Developers need to create the required connection string themselves. However, modules can at least offer two types of connection strings by default: one for the test-host to container and another for the container to container communication.

Third, developers cannot override the pre-configured connection string.

Solution

Extending the container builder to allow overriding a connection provider enables developers to customize the pre-configured connection string within modules. Moreover, instead of having a single connection string for the test-host to container communication, the provider can provide an additional connection string for container-to-container communication. Lastly, the connection provider serves as an abstraction and can be passed around without exposing the entire container instances (if necessary).

This is the initial concept:

IConnectionStringProvider c1 = new ContainerBuilder()
    .WithConnectionStringProvider(new MyProvider1())
    .Build();

IConnectionStringProvider c2 = new PostgreSqlBuilder()
    .WithConnectionStringProvider(new MyProvider2())
    .Build();

_ = c1.GetConnectionString();

_ = c1.GetConnectionString(ConnectionMode.Host);

_ = c1.GetConnectionString(ConnectionMode.Container);

private sealed class MyProvider1 : IConnectionStringProvider<IContainer, IContainerConfiguration>
{
    public void Build(IContainer container, IContainerConfiguration configuration)
    {
        // TODO: Add connection string for host and container communication.
    }
}

private sealed class MyProvider2 : IConnectionStringProvider<PostgreSqlContainer, PostgreSqlConfiguration>
{
    public void Build(PostgreSqlContainer container, PostgreSqlConfiguration configuration)
    {
        // TODO: Add connection string for host and container communication.
    }
}

Please note that since the IConnectionStringProvider interface serves as the minimal common denominator, it cannot provide additional public, module-specific properties and methods. If such properties or methods are necessary, the specific type must be used.

This issue relates to:

• https://github.com/testcontainers/testcontainers-dotnet/issues/1068
• https://github.com/testcontainers/testcontainers-dotnet/issues/1060
• https://github.com/testcontainers/testcontainers-dotnet/issues/986
• https://github.com/testcontainers/testcontainers-dotnet/pull/1053
• https://github.com/testcontainers/testcontainers-dotnet/pull/920
• https://github.com/testcontainers/testcontainers-dotnet/issues/1436
• https://github.com/testcontainers/testcontainers-dotnet/issues/1447
• and others which I do not find anymore

Benefit

Offers additional configurations developers can utilize to configure their test case/scenario.

Alternatives

-

Would you like to help contributing this enhancement?

Yes

Start by reviewing the existing ContainerBuilder, PostgreSqlBuilder, and ADO.NET connection-string abstraction, then read the related issues and pull requests listed in the description. Clarify the provider API, host/container connection modes, override behavior, and module integration before estimating the work. Done means the agreed abstraction is implemented consistently across the affected builders and its behavior is verified by the project’s tests.