{"id":5005,"date":"2026-09-03T18:48:04","date_gmt":"2026-09-03T18:48:04","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/09\/03\/test-what-you-ship-mstest-and-native-aot\/"},"modified":"2026-09-03T18:48:04","modified_gmt":"2026-09-03T18:48:04","slug":"test-what-you-ship-mstest-and-native-aot","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/09\/03\/test-what-you-ship-mstest-and-native-aot\/","title":{"rendered":"Test what you ship: MSTest and Native AOT"},"content":{"rendered":"

If you ship an application with
\nNative AOT<\/a>,
\na green managed test run leaves a gap. Native AOT compiles ahead of time,
\nremoves unused code<\/a>,
\nand requires alternatives to runtime code generation and unrestricted
\nreflection. The published application can therefore behave differently from
\nthe code exercised by the managed test process.<\/p>\n

Starting with MSTest 4.4, MSTest supports publishing and running test projects
\nas Native AOT executables.<\/strong> Source generation records which tests exist and how
\nto invoke them before trimming happens, without requiring developers to rewrite
\ntheir test classes. The result is simple: test what you ship<\/strong>.<\/p>\n

For teams with formal validation plans, including some in regulated
\nenvironments, that native run provides more representative evidence. It doesn\u2019t
\nreplace testing the final application artifact.<\/p>\n

A managed pass can still hide a deployment failure<\/h2>\n

Consider an application that serializes a receipt with System.Text.Json<\/code> and a
\ntest that covers that path:<\/p>\n

[TestClass]\npublic class ReceiptFormatterTests\n{\n    [TestMethod]\n    public void ReceiptIsSerialized()\n    {\n        var json = JsonSerializer.Serialize(new Receipt(42));\n\n        StringAssert.Contains(json, \"\"Total\":42\");\n    }\n}\n\npublic sealed record Receipt(decimal Total);<\/code><\/pre>\n
The test passes in a normal managed run because System.Text.Json<\/code> can discover
\nthe type through reflection. In a trimmed or Native AOT publish,
\nreflection-based serialization is disabled by default. The same path throws:<\/p>\n
System.InvalidOperationException:\nReflection-based serialization has been disabled for this application.<\/code><\/pre>\n
That failure is useful. It identifies an application deployment problem, not a
\ntesting-framework problem. The production code should provide generated JSON
\nmetadata, for example:<\/p>\n
[JsonSerializable(typeof(Receipt))]\ninternal partial class AppJsonContext : JsonSerializerContext\n{\n}\n\nvar json = JsonSerializer.Serialize(\n    new Receipt(42),\n    AppJsonContext.Default.Receipt);<\/code><\/pre>\n
The
\nSystem.Text.Json<\/code> source-generation guidance<\/a>
\ndescribes this behavior and the available generation modes. Serialization is
\nonly one example; native testing can also expose unsupported runtime code
\ngeneration, missing reflection metadata, or an incompatible dependency.<\/p>\n
There are two separate responsibilities here. MSTest source generation keeps
\nthe test discoverable and runnable after trimming. The JSON source generator
\nfixes the application path that the test exercises. MSTest doesn\u2019t hide the
\napplication problem; it lets the native test process expose it before the
\nproduct reaches deployment.<\/p>\n
How MSTest makes the native test executable possible<\/h2>\n
MSTest\u2019s first
\nNative AOT preview<\/a>
\narrived in April 2024. It proved that an MSTest project could become a native
\nexecutable, but the experimental engine and source generator had limited
\ncoverage.<\/p>\n
The new path moves source generation into the open MSTest toolchain and aligns
\nit with MSTest 4.4. During compilation, the generator emits:<\/p>\n