Integration testing multiple Databases for same Tests

[TheMatrixPill]

I have a Project wich should support two Databases using Ef core.

Is it possible to run the same Tests for different Databases?

I am currently using the ClassDataSource<T>(Shared = PerTestSession) Attribute to provide an TestContianer Database to the Baseclass of the tests.
Is there a way to run the tests also with a different Db (parallel or not, trying to use the Attribute a second time does not work.

[tayfuryldz]

Current TUnit can model this as multiple class data sources for one test-class constructor, which is closer to the requirement than injecting two databases into the same test instance.

There is regression coverage on current main for exactly the multiple-source behavior. ArgumentsWithClassDataSourceTests applies two class-level sources:

[ClassDataSource(typeof(IntDataSource1))]
[ClassDataSource(typeof(IntDataSource2))]
public class ArgumentsWithClassDataSourceTests(int classArg)

and TUnit verifies that the class/tests are instantiated once for each source (and, when combined with other class data, once for every supplied class case).

For two database fixtures, the corresponding shape is:

[ClassDataSource(typeof(PostgresFixture), Shared = SharedType.PerTestSession)]
[ClassDataSource(typeof(SqlServerFixture), Shared = SharedType.PerTestSession)]
public class DatabaseTests(IDatabaseFixture db)
{
    [Test]
    public async Task Same_contract_runs_for_each_database()
    {
        // test only against db
    }
}

where both fixture types are compatible with the constructor parameter. This gives each generated test-class case one database fixture, so the same tests execute independently against each implementation. It is different from ClassDataSource<T1,T2>, whose purpose is to inject several dependencies together into one case.

The current sharing semantics are also worth keeping: PerTestSession is appropriate for expensive container fixtures if you want one instance of each database for the run. Both fixture types can implement IAsyncInitializer / IAsyncDisposable so TUnit owns startup and teardown.

If the two fixtures need different construction logic or cannot share a constructor abstraction, a method/custom data source that yields a common wrapper is another option. But for “same contract tests, two interchangeable database implementations”, multiple class-level ClassDataSource(typeof(...)) entries are now directly supported and avoid duplicating the test methods.