[Enhancement]: Enable built-in support for singleton container instances

[HofmeisterAn]

Problem

Depending on the lifecycle of the test framework and the test implementation, it is quite common for each test to create a new instance of a container (Docker resource). However, this is not always desired, depending on the nature of the tests. Utilizing a container instance for more than just one test can potentially reduce test execution time and resource consumption. It is worth noting that even though each test initializes a container, it should dispose it afterward, there should be no real cases where a container is running unnecessarily (multiple times).

Solution

I am not entirely sure about the implementation details at this moment. I would like to explore and discuss various approaches first.

Benefit

Currently, each developer needs to implement the singleton pattern if they wish to initiate an instance once and use the same instance for multiple tests. Given that this is a common use case, perhaps we can enhance Testcontainers to provide built-in support for creating a singleton instance of a container, making it easier for developers to achieve this out of the box.

Alternatives

-

Would you like to help contributing this enhancement?

Yes

[FriedLychees]

Can't speak for all test frameworks, but xUnit already supports this case via its CollectionFixtures feature.

[HofmeisterAn]

Yes, I am aware of the shared context, and other test frameworks have similar functionalities. Nevertheless, every developer needs to implement the pattern over and over again and take care to start and dispose of the container instance. I think we can make it more convenient and simpler for developers to access a running (dependent) container instance in their tests (similar to Java's extensions).

[samtrion]

This could become a useful feature, especially when using multiple TargetFrameworks for testing.

Is there possibly already a "workaround" for this?

[AHarman]

Can't speak for all test frameworks, but xUnit already supports this case via its CollectionFixtures feature.

A downside to this approach is that with CollectionFixtures all the tests sequentially and xUnit does not yet natively support running tests within a given collection in parallel. xUnit 3 is looking into adding more customization for this but there's no details on when this will be released.

[0xced]

As mentioned in #996 (comment), I have a feature/Testcontainers.Xunit branch (freshly rebased on develop) where I prototyped a dedicated Testcontainers/xUnit.net integration package.

Previously, the missing WithLogger(ILogger) API was holding me to submit a pull request. Now that it shipped in version 3.8.0 nothing is holding me from opening a pull request anymore. 😄 I'll try to do it soon, please remind me If I don't.

[0xced]

Pull request #1165 is submitted. I look forward to hearing your feedback.