{"id":51273,"date":"2024-04-03T10:05:00","date_gmt":"2024-04-03T17:05:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=51273"},"modified":"2024-04-02T12:47:34","modified_gmt":"2024-04-02T19:47:34","slug":"testing-your-native-aot-dotnet-apps","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/testing-your-native-aot-dotnet-apps\/","title":{"rendered":"Testing Your Native AOT Applications"},"content":{"rendered":"

We are happy to announce that we just published an early preview of support for testing Native AOT with MSTest, and we welcome all of you to try it.<\/p>\n

This new solution is powered by a completely new testing engine that we wrote from ground up, to allow running tests in Native AOT, and that works together with the existing MSTest runner (Microsoft.Testing.Platform). We also leveraged the power of source generators, to discover tests during compilation, which solved one of the big hurdles that prevented us from compiling and running tests in Native AOT.<\/p>\n

What is Native AOT<\/h2>\n

.NET applications can be published as Native AOT<\/a>, which means that the resulting application is compiled ahead-of-time (AOT) into native code. Such applications have faster startup time, smaller memory footprint, and no dependency on .NET runtime.<\/p>\n

There are two main use cases for such applications. One is ASP.NET Core, which has added support for Native AOT in .NET 8, that takes advantage of the faster startup time. And the second use case is running applications directly on IoT devices that have limited resources and storage.<\/p>\n

Why should I test Native AOT apps?<\/h2>\n

Native AOT applications can run in environments that do not allow JITing code. Such as game consoles, or some IoT devices. Building your tests as Native AOT will allow running them even on such devices.<\/p>\n

You may also be producing a Native AOT and non-native version of your application and use compiler conditions to take different paths in your code, e.g. to work around code that RequiresDynamicCode<\/a>.<\/p>\n

Native tests can help you test such use cases.<\/p>\n

How to test your apps in Native AOT mode?<\/h2>\n

In the example below we are creating a test project that enables PublishAot and has 2 new packages installed: MSTest.Engine<\/code> and MSTest.SourceGeneration<\/code>. These packages contain our new testing engine, and source generator. We are using this test project to test our class library (not shown), that also enables PublishAot.<\/p>\n

<!-- file: UnitTestProject1.csproj -->\r\n<Project Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n  <PropertyGroup>\r\n    <TargetFramework>net8.0<\/TargetFramework>\r\n    <ImplicitUsings>enable<\/ImplicitUsings>\r\n    <Nullable>enable<\/Nullable>\r\n\r\n    <OutputType>exe<\/OutputType>\r\n    <PublishAot>true<\/PublishAot>\r\n  <\/PropertyGroup>\r\n\r\n  <ItemGroup>\r\n    <!-- \r\n      Experimental MSTest Engine & source generator, \r\n      close sourced, licensed the same as our extensions \r\n      with Microsoft Testing Platform Tools license.\r\n    -->\r\n    <PackageReference Include=\"MSTest.Engine\" Version=\"1.0.0-alpha.24163.4\" \/>\r\n    <PackageReference Include=\"MSTest.SourceGeneration\" Version=\"1.0.0-alpha.24163.4\" \/>\r\n\r\n    <PackageReference Include=\"Microsoft.CodeCoverage.MSBuild\" Version=\"17.10.4\" \/>\r\n    <PackageReference Include=\"Microsoft.Testing.Extensions.CodeCoverage\" Version=\"17.10.4\" \/>\r\n\r\n    <PackageReference Include=\"Microsoft.Testing.Extensions.TrxReport\" Version=\"1.0.2\" \/>\r\n    <PackageReference Include=\"Microsoft.Testing.Platform.MSBuild\" Version=\"1.0.2\" \/>\r\n    <PackageReference Include=\"MSTest.TestFramework\" Version=\"3.2.2\" \/>\r\n    <PackageReference Include=\"MSTest.Analyzers\" Version=\"3.2.2\" \/>\r\n\r\n  <\/ItemGroup>\r\n\r\n  <ItemGroup>\r\n    <ProjectReference Include=\"..\\ClassLibrary1\\ClassLibrary1.csproj\" \/>\r\n  <\/ItemGroup>\r\n\r\n  <ItemGroup>\r\n    <Using Include=\"Microsoft.VisualStudio.TestTools.UnitTesting\" \/>\r\n  <\/ItemGroup>\r\n\r\n<\/Project><\/code><\/pre>\n
\/\/ file: UnitTest1.cs\r\nusing ClassLibrary1;\r\n\r\nnamespace TestProject1;\r\n\r\n[TestClass]\r\npublic class UnitTest1\r\n{\r\n    [TestMethod]\r\n    public void TestMethod1()\r\n    {\r\n        Assert.AreEqual(3, new Class1().Add(1, 2));\r\n    }\r\n\r\n    [TestMethod]\r\n    [DataRow(1, 2)]\r\n    public void TestMethod2(int left, int right)\r\n    {\r\n        Assert.AreEqual(3, new Class1().Add(left, right));\r\n    }\r\n}<\/code><\/pre>\n
The complete example is available at microsoft\/testfx samples<\/a>.<\/p>\n
To run your tests, you need to publish them, then run the published executable:<\/p>\n
C:\\t\\NativeAotRunner> dotnet publish .\\TestProject1 --runtime win-x64\r\nC:\\t\\NativeAotRunner> .\\TestProject1\\bin\\Release\\net8.0\\win-x64\\publish\\TestProject1.exe\r\n\r\nMicrosoft(R) Testing Platform Execution Command Line Tool\r\nCopyright(c) Microsoft Corporation.  All rights reserved.\r\n\r\nPassed! - Failed: 0, Passed: 6, Skipped: 0, Total: 6, Duration: 7ms - TestProject1.exe<\/code><\/pre>\n
Code Coverage and TRX reports<\/h2>\n
You might notice that the example project is referencing the CodeCoverage and TRX report extension packages. They are, as their name suggests, providing Code Coverage and TRX (test results) reports.<\/p>\n
We think this is the minimum that you need to successfully add Native AOT tests to your existing pipelines, and that is why we are providing them with this early preview. Using the project above you can simply provide --coverage --report-trx<\/code> on the commandline to collect TRX and CodeCoverage report.<\/p>\n
C:\\t\\NativeAotRunner> .\\TestProject1\\bin\\Release\\net8.0\\win-x64\\publish\\TestProject1.exe --coverage --report-trx\r\n\r\nMicrosoft(R) Testing Platform Execution Command Line Tool\r\nCopyright(c) Microsoft Corporation.\u00a0 All rights reserved.\r\n\r\nPassed! - Failed: 0, Passed: 6, Skipped: 0, Total: 6, Duration: 1ms - TestProject1.exe\r\n\r\nIn process file artifacts produced:\r\n- C:\\t\\NativeAotRunner\\TestProject1\\bin\\Release\\net8.0\\win-x64\\publish\\TestResults\\jajares_RDESKTOP_2024-03-27_12_18_20.727.trx\r\n- C:\\t\\NativeAotRunner\\TestProject1\\bin\\Release\\net8.0\\win-x64\\publish\\TestResults\\8abd5db9-4d12-4778-b4f1-e24635c44df0.coverage<\/code><\/pre>\n
Here are the details of how this is set up:<\/p>\n
Running with TRX<\/h3>\n
To run with TRX report provide --report-trx<\/code> on commandline.<\/p>\n
.\\TestProject1\\bin\\Release\\net8.0\\win-x64\\publish\\TestProject1.exe --report-trx<\/code><\/p>\n
Running with Code Coverage<\/h3>\n
To generate code coverage in Native AOT mode you need to instrument the executable during dotnet publish<\/code>. This is done by providing \/p:AotMsCodeCoverageInstrumentation=true<\/code> MSBuild property:<\/p>\n
dotnet publish .\\TestProject1 --runtime win-x64 \/p:AotMsCodeCoverageInstrumentation=true<\/code><\/p>\n
And then during test run you will provide --coverage<\/code> parameter to collect code coverage of the run:<\/p>\n
.\\TestProject1\\bin\\Release\\net8.0\\win-x64\\publish\\TestProject1.exe --coverage<\/code><\/p>\n
This functionality is achieved by the two referenced NuGet packages:<\/p>\n