Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
HofmeisterAn opened this issue Sep 3, 2023 · 6 comments · May be fixed by #1165
Open

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

HofmeisterAn opened this issue Sep 3, 2023 · 6 comments · May be fixed by #1165
Labels
enhancement New feature or request

Comments

@HofmeisterAn
Copy link
Collaborator

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

@HofmeisterAn HofmeisterAn added the enhancement New feature or request label Sep 3, 2023
@FriedLychees
Copy link

FriedLychees commented Sep 15, 2023

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

@HofmeisterAn
Copy link
Collaborator Author

HofmeisterAn commented Sep 15, 2023

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
Copy link

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

Is there possibly already a "workaround" for this?

@AHarman
Copy link

AHarman commented Jan 10, 2024

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
Copy link
Contributor

0xced commented Apr 26, 2024

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 0xced linked a pull request Apr 27, 2024 that will close this issue
@0xced
Copy link
Contributor

0xced commented Apr 27, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants