Add xUnit v3 support

[mattleibow]

Adds xUnit v3 as a supported test framework in DeviceRunners, alongside xUnit v2 and NUnit. Tests written with xUnit v3 can be discovered, executed, and reported through both the visual runner and CLI runner on all platforms — Android, iOS, macOS, Windows, and WASM.

Usage

Test library setup

xUnit v3 test assemblies must be class libraries (not executables) because the MAUI/Blazor app is the host process. Reference the lower-level xUnit v3 packages:

<ItemGroup>
  <PackageReference Include="xunit.v3.extensibility.core" />
  <PackageReference Include="xunit.v3.assert" />
</ItemGroup>

Do not reference xunit.v3 or xunit.v3.core in your device-targeted TFMs — those inject a Main entry point that conflicts with the app host. You can conditionally reference xunit.v3 on the host TFM (net10.0) to enable dotnet test.

Registration

// MAUI
builder.UseVisualTestRunner(conf => conf
    .AddXunit3()
    .AddTestAssemblies(typeof(MyXunit3Tests).Assembly)
    .AddConsoleResultChannel());

// Blazor WASM
builder.UseVisualTestRunner(conf => conf
    .AddXunit3()
    .AddTestAssemblies(typeof(MyXunit3Tests).Assembly)
    .AddConsoleResultChannel());

.AddXunit3() works the same on every platform — no flags, no useReflection, no per-platform configuration. It can be used alongside .AddXunit() and .AddNUnit().

UI testing

[UIFact] and [UITheory] attributes are available via the DeviceRunners.UITesting.Xunit3 package:

using DeviceRunners.UITesting.Xunit3;

public class MyUITests
{
    [UIFact]
    public void RunsOnUIThread() { /* ... */ }
}

Separate namespace from v2: The v3 [UIFact] and [UITheory] attributes are in the DeviceRunners.UITesting.Xunit3 namespace to avoid CS0433 ambiguity when both v2 and v3 runner packages are referenced in the same project.

How it works

Discovery and execution

The runner uses xUnit v3's in-process extensibility APIs directly (ITestFrameworkDiscoverer.Find() / ITestFrameworkExecutor.RunTestCases()). No separate test process is launched — everything runs inside the app.

Threading model

• Discovery and execution run via Task.Run to escape the caller's SynchronizationContext (e.g. WinUI dispatcher), preventing deadlocks while preserving full parallelism.
• Message reporting uses xUnit v3's async MessageBus pump on threaded platforms (desktop, Android, iOS) for maximum throughput. On WASM (where Thread cannot be spawned), synchronous reporting is enabled via OperatingSystem.IsBrowser().
• Result callbacks are marshalled to the UI thread for ViewModel updates using SynchronizationContext.Post.
• No WASM workarounds degrade threaded platforms — platform detection is always runtime (OperatingSystem.IsBrowser()) rather than compile-time or based on Assembly.Location emptiness.

Platform compatibility

On Android, iOS, and WASM, Assembly.Location returns an empty string because assemblies are loaded from streams rather than files. xUnit v3's XunitTestAssembly uses this path internally and crashes when it's empty.

DeviceRunners handles this transparently with InMemoryXunit3TestAssembly — a subclass that provides a logical path derived from the assembly name. The same code path works on all platforms; the runner auto-detects whether in-memory handling is needed at runtime.

UI thread dispatch

[UIFact]/[UITheory] dispatch the entire test lifecycle (class construction, IAsyncLifetime, test method invocation, and disposal) to the UI thread.

What's in this PR

New packages

Package	What it does
DeviceRunners.VisualRunners.Xunit3	Test discovery, execution, message sinks, configuration
DeviceRunners.UITesting.Xunit3	[UIFact] / [UITheory] attributes and test case runners

Samples

• DeviceTestingKitApp.MauiLibrary.Xunit3Tests — MAUI library tests (CounterView, VisualElement, Converter, SemanticAnnouncer, UIFact/UITheory)
• DeviceTestingKitApp.BlazorLibrary.Xunit3Tests — Blazor library tests (CounterViewModel, Formatter, SemanticAnnouncer)
• DeviceTests and BrowserTests updated to load v3 test assemblies

Tests

• TestProject.Xunit3Tests — fixture assembly (facts, theories, skips, output)
• DeviceRunners.VisualRunners.Xunit3.Tests — dedicated v3 unit test project with discoverer, runner, home view model, and threading tests
• Tests follow the existing abstract-base pattern (TestDiscovererTests.Xunit3, TestRunnerTests.Xunit3, HomeViewModelTests.Xunit3)

Docs

• docs/articles/xunit-v3-support.md — quick start, package architecture, platform compatibility table, in-memory assembly handling, desktop vs device/WASM differences

Other

• Removed bUnit dependency (component rendering tests replaced with ViewModel/Formatter tests)
• Updated Directory.Packages.props and DeviceRunners.slnx
• Android Shell layout fix (WaitForPageLayout) for stable UI test navigation

Known limitations

• Custom [TestFramework] — On platforms where Assembly.Location is empty (Android, iOS, WASM), the [TestFramework] assembly attribute is bypassed. Custom xUnit test frameworks only work on desktop. Tracked upstream: xunit/xunit#3096.
• dotnet test on device TFMs — xUnit v3 device test projects cannot use dotnet test or VS Test Explorer for device TFMs. This is a fundamental xUnit v3 architecture constraint for device testing. However, dotnet test works on the host TFM (net10.0) for quick local iteration.
• PrivateAssets="compile" — The DeviceRunners.VisualRunners.Xunit3 package uses PrivateAssets="compile" on its xunit.v3 dependencies to avoid type conflicts when co-hosted with the v2 runner. Consumers must bring their own xunit.v3 package references (which they always do since they're writing xunit tests).

[Copilot]

Pull request overview

Copilot reviewed 86 out of 88 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 88 out of 90 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

test/DeviceRunners.VisualRunners.Xunit3.Tests/Testing/Xunit3RunnerAdvancedTests.cs:88

• reportedResults is a List<T> that is appended to from ResultReported callbacks. Those callbacks may be raised from multiple threads (xUnit v3 message sink is explicitly thread-safe and can report from parallel execution), so this list mutation can race and make the test flaky. Use a thread-safe collection (or protect Add with a lock).
  src/DeviceRunners.VisualRunners/ViewModels/HomeViewModel.cs:83
• StartAssemblyScanAsync now accepts a CancellationToken, but it’s only passed into discovery. If _options.AutoStart is enabled, the subsequent run (RunEverythingAsync / _runner.RunTestsAsync) ignores the token, so cancellation can still lead to a full test run starting. Consider propagating the token through the auto-run path (and early-exiting if cancellation is already requested).

[Copilot]

Pull request overview

Copilot reviewed 89 out of 91 changed files in this pull request and generated 1 comment.