MSTest 4.4 enables test projects to run using the same deployment model that the application may rely on in production, through test source generation and enabling Native AOT and trimming. The idea is not to replace the usual managed test execution, but to add a native path that exposes issues related to ahead-of-time compilation and the removal of unused code before the application ships.
According to Amaury Levé, Principal Software Engineer, using MSTest.Sdk/4.4.0 with net10.0 as the target and setting PublishAot=true enables MSTest source generation and the native executable path. MSTest.Sdk uses the Microsoft Testing Platform, or MTP, by default. Projects that still use VSTest should review the guidance for migrating to MTP, because command-line arguments, CI integration, and some supported .runsettings entries differ.
What changes in practice?
After configuring the project, the tests should be published for the same operating system and architecture targeted by the application. The source gives an example using the linux-x64 identifier, which can be replaced with values such as win-x64 or osx-arm64. After publishing, the resulting executable is run directly, or with the .exe extension on Windows.
This path reduces reliance on broad reflective assembly inspection, such as calling Assembly.GetTypes(), and uses generated attributes and delegates to create and invoke supported tests. However, source generation does not mean that Reflection is eliminated; the default ReflectionFree mode retains some fallback reflective paths. When investigating compatibility issues, MSTestSourceGenMode=Rooting can be used to preserve discovered test members while continuing reflective execution.
A limited CI path before expansion
The practical recommendation is to keep fast managed test execution for daily feedback, then select one test project directly relevant to the deployment path and add a Native AOT trial in CI. The two paths should be compared in three clear areas:
- Discovering exactly the same number of tests.
- Obtaining the same results for the tests.
- Recording native publishing and startup time separately from test execution time.
It is preferable to start the trial in a scheduled job or a release-validation stage, and move it to every pull request only if the signal it provides is worth the additional publishing and execution cost. A project that tests deployment-sensitive paths should also be selected, such as serialization, dependency injection, configuration binding, Reflection-dependent extensions, or a library for which the teams need to prove Native AOT compatibility. A project containing only simple computational tests will not provide much evidence of the application's actual readiness.
Constraints that should become acceptance gates
Some tests may pass and the process may exit successfully even though some classes were not recorded. This happens, for example, when a test class inherits the [TestClass] attribute instead of declaring it directly, or when the class is inaccessible, file-local, static, open, public, or abstract. The source indicates that diagnostic MSTEST0069 helps detect one of these cases. Therefore, matching the test count should be a release condition, not a note that can be ignored.
Other constraints include public test methods, or methods that use ref, out, or in parameters, as well as the lack of support for some static-part patterns through [AssemblyFixtureProvider]. Some MSTest SDK integrations, MTP extensions, and CI reports are also unavailable in the Native AOT path, while TRX and Code Coverage support remain available according to the article. Accordingly, analyzer warnings and build diagnostics should be treated as migration gates, not as warnings to suppress.
Why does this approach matter?
Managed testing and the Native AOT path answer two different questions: the former accelerates the development cycle, while the latter verifies that the tests themselves can run within the deployment model the application will use. This is not equivalent to comprehensive testing of the final production artifact; settings, the operating system, the architecture, external services, and packaging may differ. However, it removes an important variable: the difference in trimming and ahead-of-time compilation models between the tests and the application.
Performance improvement is not guaranteed and should not be the primary justification. Discovery and startup time may decrease through source generation, but execution time, process startup, publishing, and the remaining Reflection may dominate the total duration. The editorial reading here is that the experiment's primary value is increasing test-to-deployment fidelity, even if the speed improvement is limited. The approach also remains reversible: if the path's cost exceeds the confidence it adds, its frequency can be reduced, the selected project can be changed, or the experiment can be stopped without disrupting the managed test suite.