Integration tests: How to override service for a single test?

[VTJDailey]

Hello, I'm working with TUnit integrations and may not be understanding some of the smaller details on setting up the test version of the web application. For now I have this:

public class MyFeatureTests : IntegrationTestBase //IntegrationTestBase inherits WebApplicationTest<....> as from the documentation
{
    protected override void ConfigureTestServices(IServiceCollection services)
    {
        var fakeClock = new FakeClock(Instant.FromDateTimeUtc(DateTime.UtcNow.AddDays(-30)));
        services.RemoveAll<IClock>();
        services.AddScoped<IClock>(s => fakeClock);
        base.ConfigureTestServices(services);
    }

    [Test]
    ........

    [Test]
    public async Task TestICareAbout()
    {
        var fakeClock = Factory.Services.GetRequiredService<IClock>() as FakeClock;
        fakeClock!.Reset(...);
        ....
    }
}

It removes the singleton 'real' clock from NodaTime and replaces it with a scoped (per test I believe?) fake clock.

This works fine, but it's called for every test in the test class. In addition, within that test there's a bit of awkward code getting the IClock service and casting it back to FakeClock

How would I accomplish the same thing only for a single test method? I'm not quite sure how to hook into the SUT services and override from within an individual method, or if any such hook exists?

[thomhurst]

For the casting, I would just store the concrete type as a field you can just reference easily - And just register the same instance in DI ofc.

For per-test - Either use a separate class with different ConfigureTestServices logic, or otherwise do a check on the current test running, which is a bit fiddly.

Pseudocode:

if (TestContext.Current!.Metadata.TestName == nameof(MyClass.MyTest))
{
    RegisterMyOverride();
}

[VTJDailey]

The problem with storing the concrete type in a field is that a class field is shared among all tests so that if 2 or more tests are wanting to override, they would interfere with each other.

I figured there was some sort of hook to find metadata information on the current test, thank you for that info! Combining the metadata check on the test name and then a separate field for each test that needs the overridden service, it should be enough. But I agree that it's fiddly to match string names like that.

As for the alternate options of just creating a new test class just for the single test, is that something you'd expect as typical? Would you be surprised to see an application with a large number of single-test classes? Or is that just unremarkable? I am also experimenting with TestContainers, and definitely don't want to spawn an extra db docker image for every single test. But I believe that behavior is configurable -- I'll need to double check on their docs.

[thomhurst]

The problem with storing the concrete type in a field is that a class field is shared among all tests so that if 2 or more tests are wanting to override, they would interfere with each other.

In TUnit you get a new class instance per test. So as long as your field isn't static, you'll have separate instance fields per test too

[VTJDailey]

Oh, I had missed this! That makes more sense, thank you.

[thomhurst]

I am also experimenting with TestContainers, and definitely don't want to spawn an extra db docker image for every single test.

What I do, and recommend, is for dependencies like a database, redis, etc. in docker, is spawning one globally, tweaking your prod code to accept a table name or something via config, and then making each test use a unique name for the config, so each test becomes isolated still, but you don't have to spin up lots of docker images and lag your system