Issues with reuse, .NET test containers and SQL Server on windows/docker desktop/nunit4

[thecheesemp]

Hi,
Just wondering if anyone had any ideas or whether this is a bug.

I'm trying to switch our build running integration tests from using docker from a script to using testcontainers.

If I create our containers in the [OneTimeTestSetup] for our integrations tests like this everything works:
msSqlContainer = new MsSqlBuilder()
.WithImage("mcr.microsoft.com/mssql/server:2022-latest")
.WithLogger(new TextWriterLogger(() => TestContext.Progress, () => TestContext.Error))
.Build();

However it is extremely slow due to have to run a full set of migrations every time. I switched to trying to use .Reuse :
msSqlContainer = new MsSqlBuilder()
.WithImage("mcr.microsoft.com/mssql/server:2022-latest")
.WithLogger(new TextWriterLogger(() => TestContext.Progress, () => TestContext.Error))
.WithReuse(true))
.Build();

This works for some tests but not others. I get errors like this:
Microsoft.Data.SqlClient.SqlException : Database 5 cannot be autostarted during server shutdown or startup.
(I tried adding .WithName("IntegrationTestDB")/.WithAutoRemove(false)/.WithCleanUp(false) make no difference).

The container is disposed after each test set which is I presume causing the shutdown? I've tried all sorts of different wait strategies but with zero luck too.

Is there a way to do this? Our pipeline times out after an hour so I need some reuse if I'm to switch to testcontainers.

Thank you.

[HofmeisterAn]

The container is disposed after each test set which is I presume causing the shutdown?

Don't dispose explicitly, otherwise the container will stop.

But this isn't really the intended use case for reuse, especially not in CI. You still need to think about your test (session) lifecycle. When are instances shared across tests, when aren't they, which tests are destructive (e.g. modify data), and which aren't, etc.?

[...] from using Docker from a script to using Testcontainers. [...]
However it is extremely slow because it has to run a full set of migrations every time.

So this must have already been an issue back then, right? Or how did you handle the slowness when using scripts?

Here's what I'd do:

• Categorize and group tests into destructive, data-manipulating, or simply incompatible tests.
• Create a single instance with the test framework's approach, then reuse that instance across all compatible tests.
  • For NUnit SetUpFixture or global OneTimeSetUp.

If that's still too slow, I'd cache the database migration and build specific images so I don't have to run the full migration every time. Some CI providers also support file caching, which you can use to cache an image with the migration pre-applied.

[thecheesemp]

Thank you so much for the response. I have carried on playing around with this and removing the container dispose does seem to fix most, if not all of my issues (still 3 tests failing but may be something else - still checking). Feels a little odd to ignore a required dispose but if needs must...

Just to clarify - The current setup is to run the full build including unit tests, then run a script to setup a new container/database, run migrations, then run all the integrations tests against that one container/database.

I will though double check the use of [OneTimeSetUp] - maybe I have got something wrong. I've shared one between the different test classes via a base class. Maybe there is a better way to do so.

I'll either come back and mark your post as the answer or come back with further questions today.

[thecheesemp]

Yep that seems to have fixed it. It never occurred to me to not dispose... Thanks for the help.