iOSDotNetTest

A prototype iOS "project template" for dotnet test.

See the Android equivalent here.

Usage

Run tests on the iOS simulator:

$ dotnet run
...
[PASSED] iOSDotNetTest.Test1.TestMethod1
[FAILED] iOSDotNetTest.Test1.TestMethod2
[SKIPPED] iOSDotNetTest.Test1.TestMethod3
Results: passed=1, failed=1, skipped=1
TRX report: /path/to/TestResults/_Machine_2026-03-10_19_51_43.trx

Then collect the TRX results from the simulator:

$ dotnet build -t:GetResults
...
Test results copied to /path/to/TestResults/

How It Works

The app uses UIApplication.Main() with an AppDelegate to establish a proper UIKit run loop. This prevents iOS from watchdog-killing the app during long test runs, which can happen when running tests directly from the entry point without a UI run loop.

MSTest runs on a background thread from AppDelegate.FinishedLaunching(). A custom ResultConsumer logs per-test pass/fail/skip results to the console and calls Environment.Exit() once the TRX report is written, signaling completion.

dotnet run handles the full build → install → launch cycle via the iOS workload's built-in mlaunch integration. The GetResults MSBuild target uses xcrun simctl to locate the app's data container and copy TRX files locally.

Why not XCTest?

Apple's native test infrastructure uses .xctest bundles — dynamic libraries that xcodebuild test injects into a host app at runtime. We explored this approach on the XCTestFramework branch, but running tests from AppDelegate.FinishedLaunching() is the better path for now because:

1. New project type — the iOS workload would need to produce .xctest bundles (dylibs) instead of app executables, requiring a new OutputType and changes to the native linking pipeline in dotnet/macios.
2. Developer framework support — Microsoft.iOS doesn't ship bindings for XCTest. It's a "developer only" framework not included in standard SDK search paths, requiring custom linker flags (-F, -rpath) and either new bindings or raw P/Invokes.
3. Two-project requirement — in Xcode, tests require both a host .app and a .xctest bundle as separate targets. This doesn't map to other .NET platforms (Android, Windows) where a single test project is sufficient.
4. Unclear benefit — for running MSTest on a simulator, the main gain from native .xctest support would be the ability to run tests inside app extensions, bundles, or plugins. For the common case, the current approach works just as well.

Workarounds

• MtouchInterpreter=all: Disables AOT compilation and uses the interpreter for all assemblies. MSTest platform DLLs have IL linker/AOT failures on iOS.
• GenerateTestingPlatformEntryPoint=false: MSTest SDK generates a Main() method that conflicts with our top-level statements entry point.