How should I test my code when using .NET SDK Container builds?

[baronfel]

On StackOverflow the question came up of how to test applications that previously were tested as part of building the final image. This might have looked like a Dockerfile like this (simplified):

RUN dotnet build
RUN dotnet test --no-build
RUN dotnet publish

It is possible using the container building tools to run your tests in a container. You'll need to

• build the test project into a container separately
• you'll also need to change from using an inferred ContainerBaseImage to using an explicit one, and
• tell the generated container to run the tests

Since you'll likely want to test your app using dotnet test, you'll need to set ContainerBaseImage to an image that contains an SDK install - most likely mcr.microsoft.com/dotnet/sdk:<SOME_TAG>. Altogether this might look like adding the following to your test project:

<PropertyGroup>
  <ContainerBaseImage>mcr.microsoft.com/dotnet/sdk:8.0-preview</ContainerBaseImage>
</PropertyGroup>

Having to 'eject' like this feels kind of bad, so we'll likely do some work here to allow you to choose a different Microsoft base image without also having to change the tag you'd like to use.

You'll also want to change the command that's run when you execute the container. Since your test project is already built, you want to run the equivalent of dotnet test path/to/test/project.dll. You do this by adding ContainerEntrypointArgs to set the command. This looks something like:

<ItemGroup>
  <ContainerEntrypointArgs Include="test;$(TargetFileName)" />
</ItemGroup>

(TargetFileName is an MSBuild property that the SDK has created at this point that points to the expected .dll file for this project).

However I'd like to challenge the need to test in containers at all. Most container environments bring overhead that can shorten the test loop - why not test your code in a Linux environment (either in CI or locally via tools like WSL/etc). One of the goals of the containerization effort is to enable developers to stay in the 'native' .NET toolchain as much as possible and not have to eject to isolated environments.

[BeyondEvil]

However I'd like to challenge the need to test in containers at all. Most container environments bring overhead that can shorten the test loop - why not test your code in a Linux environment (either in CI or locally via tools like WSL/etc). One of the goals of the containerization effort is to enable developers to stay in the 'native' .NET toolchain as much as possible and not have to eject to isolated environments.

I agree with this!

However, how would you solve integration-testing when you depend on supporting services like Redis, MySql, etc.? In our case we load these using a compose-file.

[baronfel]

For that specific scenario I've seen lean on the TestContainers project for providing a catalog of well-defined container definition and orchestration tools that can be spun up and torn down as your tests require them.

[BeyondEvil]

Thanks for the fast reply and the tip!

But from the docs it looks like I need to refactor my tests to use TC?