Add TUnit.AspNetCore.Core that does not depend on the TUnit metapackage?

[georg-jung]

My solution currently consists of these projects:

• Contoso.Core
• Contoso.Web (Blazor InteractiveServer, Minimal API)
• Contoso.Tests (tests the core)
• Contoso.Web.Tests (tests the Blazor parts using bUnit, integration tests for Minimal API)
• Contoso.Testing (shared test infra)
• Contoso.TestHost (test orchestrator project)

I added the TestHost project because I have some shared test infrastructure that is expensive to create (Postgres testcontainer with data seeding) and want to share it between Contoso.Tests and Contoso.Web.Tests using SharedType.PerTestSession.

Currently, Contoso.Tests and Contoso.Web.Tests depend on TUnit.Core; Contoso.TestHost on TUnit (the metapackage).

Now, I want to leverage TestWebApplicationFactory from TUnit.AspNetCore which would require Contoso.Web.Tests to depend on TUnit.AspNetCore. But TUnit.AspNetCore in turn depends on the TUnit metapackage, which would make Contoso.Web.Tests a test app itself instead of a test library.

How to handle situations like this?

Should I accept the dependency and e.g. configure my csproj like this (didn't check if that'd work):

<IsTestProject>false</IsTestProject>
<IsTestingPlatformApplication>false</IsTestingPlatformApplication>
<IsTestingPlatformEnabled>false</IsTestingPlatformEnabled>

Or should TUnit.AspNetCore actually depend on a to-be-created TUnit.AspNetCore.Core or similar that could contain the required code without depending on the TUnit metapackage?

[thomhurst]

Hmm yeah you're right - bit of an oversight on my part. It should probably just depend on TUnit.Core, and users bring in TUnit or TUnit.Engine themselves. Be a bit of a breaking change for me to do this if there's users only consuming the aspnet package at the moment 😭

[georg-jung]

I thought about the breaking character too. I think this is fixable without breaking anyone by introducing TUnit.AspNetCore.Core and making the current TUnit.AspNetCore depend on it. That would unblock people like me but wouldn't break anyone, I guess. The naming is somewhat cumbersome though I guess...

[thomhurst]

Yeah it's a good idea - thanks! It's probably the easiest approach 😄

[georg-jung]

For ref: done in #5474

[maciejeem]

I think its broken again with adding reference to TUnit.OpenTelemetry in .Core project

[thomhurst]

What do you mean? Do you have an error?

[maciejeem]

yes, TUnit.OpenTelemetry has dependency on TUnit and then my library project for common testing infrastructure is being recognised as tests project

[thomhurst]

Pushing out an update shortly

[KNAPPzoebl]

We also have the same problem with the TUnit.Aspire project, that pulls in the "TUnit" package and therefore every library that only imports TUnit.Aspire is recognized as test project. This in turn also affects the TUnit.OpenTelemetry package (since it pulls in TUnit.Aspire and therefore TUnit).

Solution could be the same as for the TUnit.AspNetCore project:

• Introduce a new TUnit.Aspire.Core library with a reference only to TUnit.Core
• Move all the code from TUnit.Aspire to the new TUnit.Aspire.Core library
• Keep the reference to TUnit.csproj in the TUnit.Aspire package, but now add the reference to TUnit.Aspire.Core

On the other hand, I think it would be more intuitive if the TUnit package is the only project that configures the project as "TestProject" - and all other packages would then just be "extensions". Test project configuration would then be always the same - adding TUnit + the extension projects you need (aspire, openTelemetry, mocks, ...).
If I am just creating a library for common test utilities or shared infrastructure, then I just use the TUnit.Core package + the extensions I want to configure.

If the current approach of creating separate packages with the .Core extension (e.g. TUnit.Aspire.Core), then it would be very helpful to have a hint in the documentation that "shared infrastructure library projects should only depend on TUnit.x.Core, because the otherwise are recognized as test projects).

[thomhurst]

@KNAPPzoebl try v1.55