AnyUnit.TestingPlatform 1.2.1

AnyUnit.TestingPlatform

Microsoft.Testing.Platform (MTP) adapter for AnyUnit - the same dotnet test/dotnet run-compatible entry point real NUnit/xUnit's own MTP mode gives you (EnableNUnitRunner/EnableMSTestRunner), for an AnyUnit test project - C# or F# alike.

Usage

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <EnableAnyUnitRunner>true</EnableAnyUnitRunner>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="AnyUnit.TestingPlatform" Version="*" />
</ItemGroup>

That's it - a real entry point is generated for you, via Microsoft. Testing.Platform.MSBuild's own official generator, and the project becomes directly runnable: dotnet run, or dotnet test if it's included in your solution. This works the same way for an .fsproj as a .csproj - the generator genuinely emits real F# source there, not just C#, so there's no F#-specific setup needed.

OutputType is set by the project, not by the package, for the same reason MSTest's EnableMSTestRunner asks the same of you: the package does set it as a fallback, but from its .targets, which is after the SDK has already decided the output's extension - fine for a .NET 10 build (which is a .dll either way), but a net48 build would come out as Tests.dll instead of Tests.exe. Found by a real consumer adding a net48 target.

By default the generated entry point tests the project's own entry assembly - the normal case, when EnableAnyUnitRunner is set directly on the project that is the test assembly. A satellite runner project that only ProjectReferences the real test assembly instead lists it explicitly, by simple assembly name:

<ItemGroup>
  <AnyUnitTestAssembly Include="MyRealTestAssembly" />
</ItemGroup>

If you'd rather not have a dotnet test/MTP-integrated entry point at all, see AnyUnit.Runner.Bootstrap instead - a plain console Runner.Run(platform), its own simpler output format, no MTP package dependency.

AnyUnit's own results.json (--report-anyunit-json)

dotnet run -- --report-anyunit-json
dotnet run -- --report-anyunit-json results.json

Writes the same results.json the console runners produce with -o - the same schema, from the same serializer, so anything that reads one reads the other. That includes anyunit-report, which converts it to JUnit/TRX/NUnit/ xUnit/CTRF/HTML/Markdown, and merges several runs' files into one.

Unlike --report-trx, this needs no extra package - it's built into AnyUnit.TestingPlatform itself, since it's AnyUnit's own format rather than a general MTP one.

The path is optional. Given one, it's used as-is (relative to the current directory, like any other -o); given none, a timestamped file is written under --results-directory, the way --report-trx behaves. A discovery-only run (--list-tests) writes nothing at all: it produces no results, and an empty results file is something AnyUnit's own tooling treats as a failure rather than as "nothing ran".

Telling runs apart (--platform-suffix)

dotnet run -- --report-anyunit-json --platform-suffix nightly

The platform id an MTP run reports is the auto-detected one (net10-osx-arm64), the same as the console runners report. --platform-suffix appends a label to it (net10-osx-arm64-nightly) - the same thing anyunit-runner run -p does - for when two runs of the same assembly on the same OS/arch/framework are genuinely different things and should not merge into one column of a combined report. (Before 1.2.1 an MTP run always reported -mtp on the end; if you were relying on that, pass --platform-suffix mtp.)

browser-wasm, without a browser

EnableAnyUnitRunner works in a browser-wasm project too (an Sdk.BlazorWebAssembly project with a plain console Main - see WhoTestsTheTesters/Tests/BasicTests.Wasm.Mtp). dotnet.js boots such a build directly under node or bun, and Microsoft.Testing.Platform's pipeline runs unmodified on Mono-wasm there. One difference from a desktop run: a results file lands in Emscripten's in-memory filesystem, so the JS harness copies it out afterwards - that project's wwwroot/runtests.mjs is the whole recipe, a dozen lines. Known rough edges: --list-tests prints the summary rather than the names, and an error path that prints usage (an unknown option, say) crashes looking up the process's own path.

Other MTP extensions (TRX, and anything else)

EnableAnyUnitRunner registers AnyUnit.TestingPlatform as a TestingPlatformBuilderHook - the same generic extensibility point every other MTP extension package uses - so any of them just work by adding their own PackageReference, with no AnyUnit-specific glue needed. For TRX output specifically:

<ItemGroup>
  <PackageReference Include="Microsoft.Testing.Extensions.TrxReport" Version="*" />
</ItemGroup>

dotnet run -- --report-trx

Same idea for Microsoft.Testing.Extensions.Retry, Microsoft.Testing.Extensions.CrashDump, or any future MTP extension - AnyUnit.TestingPlatform itself doesn't need to know about any of them individually.