testcontainers / testcontainers-dotnet

A library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions.

Testcontainers

Testcontainers for .NET is a library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions. The library is built on top of the .NET Docker remote API and provides a lightweight implementation to support your test environment in all circumstances.

Read the documentation here

License

See LICENSE.

Copyright

Copyright (c) 2019 - 2024 Andre Hofmeister and other authors.

See contributors for all contributors.

---

Join our Slack workspace | Testcontainers OSS | Testcontainers Cloud

testcontainers-dotnet's Issues

Update NuGet dependencies with minor improvements

Add pre-configured database RabbitMQ

Add Dependabot

Add `Entrypoint` to builder pattern

Add Dockerfiles support

Prepare new release

Add API call to query running Docker engine (OSType)

Add code of conduct

Add pre-configured database CouchDB

Add basic Docker features

Extend ContainerBuilder with basic Docker functionalities such as:

• Check if Docker is up and running. (We will do that in another issue)
• WithLabel
• WithName
• WithEnv
• WithCmd
• WithExposedPort
• WithVolume or WithMount
• Run docker-compose.yml(We will do that in another issue)
• Add XML documentation.
• Use interfaces instead of concrete implementation.
• Improve Docker calls in GenericContainer keep them asynchronous.
  • Use proper return types.
  • Protect container id.

Support authentication again private Docker Hubs

Clarity on libraries

Is your feature request related to a problem? Please describe.
I'm a bit confused at the moment I saw that you are a contributor on https://github.com/testcontainers/testcontainers-dotnet. What was the reason you created dotnet-testcontainers instead of continuing on the other one ?

Describe the solution you'd like
Maybe add a section to the readme how this relates to testcontainers-dotnet

Describe alternatives you've considered

Additional context

Replace StyleCop configuration with EditorConfig

Add `WorkingDir` to builder pattern

Publish random port

Is your feature request related to a problem? Please describe.
At the moment it is possible to publish a port with a specified binding pair (host, container) whereas in some scenarios I'd like to be able to just specify the container port and let the engine decide on the published host port e.g. docker run -p 80 XZY. This helps in scenarios such as running a database in integration test scenarios on two points:

• You can still run for instance a postgres instance on the default port
• You can run test in parallel

Describe the solution you'd like
Overload for WithPortBinding that accepts only the container port

Describe alternatives you've considered
New method WithRandomPortBiding would make it more clear to the user

Cheers & let me know if you like me to create a PR for it

Add missing function to get the Docker container exit code

Add missing function `WithDockerCompose`

Is your feature request related to a problem? Please describe.
I love the approach of having a single container scenario for a test case but there are also scenarios where I'd like to spin up a whole set of containers and therefore use docker-compose as declaration.

Describe the solution you'd like
I'd like to spin up a set of containers by specifying a docker-compose.yml similar to the Java version https://www.testcontainers.org/modules/docker_compose/

Describe alternatives you've considered
Not sure If there is one

• configuring the things as in the compose in code seems odd to me and leads to duplication of configuration and most of the times docker-compose.yml will also be used to deploy the application under test this would be strange.

Additional context
Also other library authors could benefit from such an approach, I happen to know that https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks is using compose and I think it would be great improvement on there development experience (since you don' t have to remember starting the containers in advance ;) )

Cheers & let me know what you think of the idea

Add missing test for Entrypoint

Split DatabaseContainerTest into own classes

Add pre-configured container Redis

Return new instance on every fluent invocation (builder)

Have a look at the implementation of LINQ and https://github.com/twitchax/Sheller for example.

Bind host port to default container database port

Update pre-configured Testcontainers

Is your feature request related to a problem? Please describe.

The pre-configured Testcontainers (Docker base image versions) are outdated.

Describe the solution you'd like.

Update the pre-configured Testcontainers to the latest version.

• MySql
• PostgreSql
• Redis
• RabbitMQ

Describe alternatives you've considered.

-

Additional context.

-

Add pre-configured database PostgreSql

Add pre-configured database MySQL

Add missing wait strategy to test if database containers are up and running (ODBC)

Replace or extend WaitUntilPortsAreAvailable: https://github.com/HofmeisterAn/dotnet-testcontainers/blob/e23d1eb8b6ea20fbf748fa0158e67a88719415c1/src/DotNet.Testcontainers/Core/Wait/WaitUntilPortsAreAvailable.cs#L15

• PostgreSql
• MySql
• MsSql
• CouchDb
• Redis
• RabbitMq

Add wait strategy to capture log messages

Get container information such as IPAddress

• IP Address
• Mac Address

Skip tasks with env variables for pull requests

Remove language-ext dependency

• DockerMetaDataClient
• TestcontainersImage
• TestcontainersContainer

Add icon for NuGet package

Move Dockerfiles archive into its own class

https://github.com/HofmeisterAn/dotnet-testcontainers/blob/c985443a77096edd82cdb4dc20a6bc8bb9af3d82/src/DotNet.Testcontainers/Clients/TestcontainersClient.cs#L161

Subdirectories are not part of the Dockerfile archive

https://github.com/HofmeisterAn/dotnet-testcontainers/blob/c985443a77096edd82cdb4dc20a6bc8bb9af3d82/src/DotNet.Testcontainers/Clients/TestcontainersClient.cs#L180

Forward errors if Docker API calls fail

This bug is in most cases related to TestcontainersClient. Is, for example, the required host port already in use, Testcontainers does not throw any errors. It will wait forever until the container is created (this will never happen).

Add missing function to purge orphaned containers if they are not disposed

Is your feature request related to a problem? Please describe.
In certain circumstances containers remain when tests are aborted or fail with an error.

Describe the solution you'd like
It seems like AppDomain.CurrentDomain.ProcessExit and Console.CancelKeyPress is not working properly (at least on macOS) e. g. STRG + C does not exit the application gracefully. Any other way? See also: dotnet/coreclr#8565.

Describe alternatives you've considered
We can probably use Microsoft.Extensions.Hosting, however, it seems like not working reliable on macOS. IHostedService.StopAsync gets "skipped".

Additional context
n/a

Add builder pattern WithWaitStrategy

Add an additional option to set custom wait strategies to complete the Testcontainer asynchronous start task.

Merge of `Entrypoint` and `Command` does not work for old configurations

TestcontainersConfiguration line 52 is not called. Merge of Entrypoint and Command does not work.

Replace Azure Pipelines build definitions with azure-pipelines.yml

It seems like AppDomain.CurrentDomain.ProcessExit and Console.CancelKeyPress is not working properly (at least on macOS) e. g. STRG + C does not exit the application gracefully. Any other way? See also: dotnet/coreclr#8565.

Update build pipeline, disable telemetry and first time experience

Get random generated port from container

User defined wait strategies will be overwritten

Remove useless Lazy<T> in build scripts.

Add missing function to switch between Docker engine Linux and Windows

Add switch to change Docker engine between Linux and Windows, to support both container operating systems (SwitchWindowsEngine , -SwitchLinuxEngine).

Add missing test for TestcontainerConfiguration

Add native Windows container support

If Docker runs with Windows engine (DockerCli.exe -SwitchWindowsEngine), .NET Testcontainers supports Windows container already. However, the behavior is not convenient. We need a simple and convenient solution to switch between both engines within the library.

Add pre-configured database MSSQL

Reduce the amount of params in TestcontainersBuilder

Add documentation

Are there any frameworks or techniques for good documentation? Maybe something like AsciiDoc or GitHub Wiki?

Add `LogConsumer` to builder pattern

Add commit message guidelines to CONTRIBUTING.md