1

I have a .NET Core project and a xUnit project to test it.

I later added support to Docker to my main .NET Core project. I target Linux and I added a bunch of operations in my Docker file. My Docker image is hosted on Docker Desktop for Windows. My project now requires to run on Docker Linux since it refers to resources I added in the Docker file.

I'm confused with what to do with my xUnit project. Should I add Docker support to it? I don't want to replicate the content of my main project's Docker file to the xUnit's Docker file since it might change and it will build an image that is unnecessarily large for the unit project.

Can I call my main project's image from my xUnit image? Or can I do without adding support to Docker to my unit project?

Thanks!

PS: I use Visual Studio 2019 on Windows

Benjamin Maurer
  • 23
  • 5

4 Answers4

4

You can run them like always from Visual Studio or directly in the build pipeline with dotnet test

But in my opinion the better way is to run them in the intermediate docker image (build image) to ensure that your application is running also in docker context by simply calling dotnet test in there

Well documented example: Running dotnet test in docker (Step 5)

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-alpine AS build
WORKDIR /app
COPY *.sln .
COPY src/Example.Service/*.csproj ./src/Example.Service/
COPY test/Example.Service.UnitTest/*.csproj ./test/Example.Service.UnitTest/
COPY test/Example.Service.ComponentTest/*.csproj ./test/Example.Service.ComponentTest/
RUN dotnet restore
# copy full solution over
COPY . .
RUN dotnet build
FROM build AS testrunner
WORKDIR /app/test/Example.Service.UnitTest
CMD ["dotnet", "test", "--logger:trx"]
# run the unit tests
FROM build AS test
WORKDIR /app/test/Example.Service.UnitTest
RUN dotnet test --logger:trx
# run the component tests
FROM build AS componenttestrunner
WORKDIR /app/test/Example.Service.ComponentTest
CMD ["dotnet", "test", "--logger:trx"]
# publish the API
FROM build AS publish
WORKDIR /app/src/Example.Service
RUN dotnet publish -c Release -o out
# run the api
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine AS runtime
WORKDIR /app
COPY --from=publish /app/src/Example.Service/out ./
EXPOSE 80
ENTRYPOINT ["dotnet", "Example.Service.dll"]
Martin
  • 3,096
  • 1
  • 26
  • 46
1

enter image description here

You'll require 5 separate images to work with

  1. Start with SDK
  2. Create a build image (with only build project and no test project)
    • Build the project (this saves more space)
  3. Create a test image (with build project and test projects)
    • Build the project
    • Run the tests
  4. Start with runtime image
  5. Build the final image copying output from 2a.
Ziaullah Khan
  • 2,020
  • 17
  • 20
0

There is a simple way to use test containers. https://github.com/isen-ng/testcontainers-dotnet

Yevheniy Tymchishin
  • 708
  • 8
  • 19
0

Thanks all.

Still would like to keep low coupling and separate my main project and its Dockerfile from my unit test project. My unit test can't run as it is because it misses resources that are in the main project's docker image.

Apparently Visual Studio doesn't support running unit tests in docker (https://developercommunity.visualstudio.com/idea/554907/allow-running-unit-tests-in-docker.html).

Benjamin Maurer
  • 23
  • 5
  • In .NET core, a test project is a .NET executable just like any other. Therefore, if you create two separate dockerfiles, with one being for your testing image, the "main" project's code would be considered a dependency. Depending on how you are are testing, you could omit the web/HTTP dependencies from this test project and docker image. You don't get the friendly UI of Visual Studio, but creating two separate images for main project deployment and unit testing is possible. – ryanwebjackson Mar 06 '22 at 21:49
  • Re. the size of the test image, it will necessarily be larger, unless you architect it in such a way that you are using HTTP to call into your main project, and at that point you are doing integration testing and not unit testing. – ryanwebjackson Mar 06 '22 at 21:49