testfx holds two different things: a new test host and the framework everyone already uses

A platform and a framework in one tree

The repository description is the first thing to parse, because it contains two products. It holds the source code of Microsoft.Testing.Platform, described as a lightweight alternative to VSTest, as well as the MSTest adapter and framework. The README puts it the same way: this repository is the home for Microsoft.Testing.Platform and extensions, as well as MSTest.

These are not the same thing and they do different jobs. MSTest, Microsoft Test Framework, is the testing framework for .NET applications: it lets you write tests, use Test Explorer, create test suites and apply the red, green and refactor patterns. It is described as a fully supported, open source and cross-platform test framework with which to write tests targeting .NET Framework, .NET Core, .NET, UWP and WinUI on Windows, Linux and Mac.

Microsoft.Testing.Platform is the layer underneath, the part that discovers and runs the tests and reports the results, and its stated ambition is to be a lighter alternative to VSTest, the test host that .NET builds have used by default for years. The overview is linked from the README at aka.ms/mtp-overview.

The reason they live in one repository is that they are versioned and released together and share the same build system. The repository layout shows how large that is: src/ and test/ for the code, several solution filters including MSTest.slnf, Microsoft.Testing.Platform.slnf, NonWindowsTests.slnf and WindowsDebugUnitTests.slnf, an eng/ directory for the build infrastructure, azure-pipelines.yml with several specialised variants including a codeql pipeline, and a Directory.Packages.props for central package version management.

For a reader trying to understand the .NET testing landscape, this repository is where the seam between the old host and the new one is visible.

Five packages, and the split is not arbitrary

MSTest ships as a set of NuGet packages, and the table in the README explains the boundaries, which is the part that matters when you add them to a project.

MSTest is a meta package that simplifies referencing all recommended MSTest packages, so most projects take that one and stop thinking about it. MSTest.TestFramework contains the libraries for writing tests with MSTest, and to ensure the discovery and execution of your tests you install the MSTest.TestAdapter package. MSTest.TestAdapter contains the adapter logic to discover and run tests, and for access to the testing framework you install the MSTest.TestFramework package. MSTest.Analyzers contains code analyzers and code fixes for MSTest. And MSTest.Sdk is an MSBuild Project SDK package that greatly simplifies a test project structure, with details in the MSTest SDK overview.

The framework and adapter split is the part to understand. Writing a test needs the framework, and having the framework alone does not make a test runnable, because something has to find the tests and execute them. That is the adapter's job. The consequence is that a project that already references the framework still needs the adapter, and the README's wording on both packages says so from both directions.

The analyzers are the least discussed of the five and one of the most useful. Code analyzers and code fixes for MSTest means the mistakes that make a test wrong rather than failing, a test that asserts nothing, a test that catches an exception that is not thrown, are reported at compile time by the compiler's own analysis pipeline rather than being discovered later.

The SDK is the newest of the set in practical terms, since an MSBuild Project SDK replaces the boilerplate project file with a small declaration, and for a test project that boilerplate is a meaningful part of the noise.

The package channels include an internal dogfood feed

Each package in the table is published through three channels, and the third one is unusual enough to notice.

There is a stable version, a preview version, and a dogfood version, and the dogfood column points at an Azure Artifacts feed, the dnceng public artifacts feed for test tools, where the versions are listed for each package separately. The preview column points at the standard prerelease listing on nuget.org.

The dogfood feed is the mechanism that lets the team run their own builds before they are published anywhere, and the fact that the table lists a dogfood version for every package means the internal artefacts are addressable by name and version, not just by a floating feed URL. For a project that wants to try an unreleased fix, that feed is the source of the build that will become the next preview release.

The release history shows how the two projects move together. The recent tags are v4.5.1 and v4.5.0, both on 2026-10-07, and v4.4.1 on 2026-09-16, and the topic list on the repository carries mstestv2, mstestv3 and mstestv4, which is a reminder that the framework has been through several major versions and that the naming in the wild is not consistent.

The repository is not archived, the last push was on 2026-10-15, and the licence is MIT. One line in the README is worth keeping in mind when you look at a downloaded package rather than the repository: the LICENSE and ThirdPartyNotices in any downloaded archives are authoritative, and the repository root carries LICENSE.PLATFORMTOOLS.txt and THIRD-PARTY-NOTICES.TXT alongside the main LICENSE.

The samples show the platform talking to other frameworks

The samples/ directory is where the repository explains the platform's reach better than the README does, because the folder names are the argument.

There is the Playground and a public/ directory, a BrowserPlayground, an FSharpPlayground, an FxExtensibility sample, a CtrfPlayground, and most tellingly an NUnitPlayground.

The NUnit sample is the interesting one. It exists because the platform is a runner, and a runner that only ran MSTest would be a replacement for VSTest rather than a general test host. The presence of a sample that drives tests written in another framework is a statement about the direction of the project, and it also tells you the shape of the integration work: the platform is something a test framework plugs into, not something that replaces the framework underneath your test code.

The other samples cover the edges. A browser playground is about running tests in a browser rather than on the.NET host, which is the kind of thing a test host cannot do on its own. FxExtensibility is about extending the framework's own extension points. CtrfPlayground is another sample, and it sits alongside a separate solution in the repository, MutationTesting.slnx, which is a strong hint that test reporting and mutation testing are treated as first class extension scenarios rather than afterthoughts.

The FSharpPlayground is there because the repository has to work with F# projects, which have their own project file conventions, and the presence of a playground for them rather than a special case in the SDK is a deliberate choice about where the complexity lives.

Building the repository is a set of scripts and solution filters

The build and test entry points are visible in the top level, and the shape of them is a good description of how the project is developed.

There is build.sh and build.cmd, test.sh and Test.cmd, restore.sh and restore.cmd, and open-code.cmd and open-vs.cmd for launching the repository in a code editor or in Visual Studio. The Windows and Unix variants of every script sit side by side, which is consistent with a project that has to build on Windows, Linux and Mac.

The solution files are filters rather than a single solution, which is the mechanism for building a subset. There is TestFx.slnx, the whole solution in the newer format, and then filters for MSTest.slnf, Microsoft.Testing.Platform.slnf, NonWindowsTests.slnf and WindowsDebugUnitTests.slnf. So a contributor working on the framework opens one filter, and one working on the platform opens another, and there is a filter for the tests that only run off Windows and one for the Windows debug unit tests.

The supporting configuration is thorough. global.json pins the SDK, Directory.Build.props, Directory.Build.targets and Directory.Packages.props handle shared build settings and package versions, and .globalconfig carries the code analysis configuration for the whole tree. There is a .jscpd.json for copy and paste detection and a stryker-config.json for mutation testing, and the presence of both of those says something about the standards the code is held to, since mutation testing in particular is the slowest and most expensive way to check that a test suite means something.

For the pipeline there are azure-pipelines.yml plus a dedicated codeql pipeline and a windows debug slim pipeline, and the .azuredevops/ and eng/ directories hold the definitions.

What the platform changes, and what it does not

The honest way to evaluate Microsoft.Testing.Platform is against the thing it replaces, and the repository's own framing is that it is a lightweight alternative to VSTest.

The difference in approach is architectural rather than cosmetic. VSTest is the established test host that the platform is positioned against, and the project's own framing is that the platform is the lighter alternative. The platform's model is that the test project itself becomes the executable, with the platform providing the run mode, the reporting and the extensions, and the project no longer depends on a separate host process to start.

What that buys is a smaller dependency surface and a test binary that can be run directly, which matters in containers and in CI where the host's assumptions about installed tooling are a frequent source of friction.

What it does not buy is parity for free, and the README points at the right place to check. The documentation directory is described as containing information about the history, context, and supported or unsupported features, and it gathers the various official documentation pages on learn.microsoft.com about MSTest. The features that the platform does not support are documented rather than assumed, and a team migrating a large suite should read that list before assuming equivalence.

The other limit is scope. This repository is the platform and the MSTest stack, and while the samples show the platform hosting other frameworks, the packaging here is the MSTest packaging. A team that has standardised on NUnit or xUnit and wants a modern host is looking at the platform, not at these five packages.

Licence, notices and the maintenance position

MSTest is licensed under the MIT licence, with the LICENSE file at the root of the repository and the note that the LICENSE and ThirdPartyNotices in any downloaded archives are authoritative. That last clause is worth understanding properly. The repository is the source, but what a consumer actually installs is a NuGet package, and the package can carry notices that are generated at pack time from the dependency graph. The repository root carries LICENSE.PLATFORMTOOLS.txt and THIRD-PARTY-NOTICES.TXT for exactly this reason, since the platform pulls in third party code that has its own terms.

The maintenance position is the strongest part of the picture. The repository is not archived, the last push was on 2026-10-15, and two release tags landed on 2026-10-07 alone, v4.5.0 and v4.5.1, after v4.4.1 in September. The build badge points at the dnceng public Azure DevOps pipeline, so the project is built on Microsoft's own infrastructure and is not a volunteer effort.

The governance artefacts are there too, with CONTRIBUTING.md, a CODE_OF_CONDUCT.md, AGENTS.md, a .copilot directory and a .mcp.json, which together tell you that the project is worked on by people and by automated tooling, and that the instructions for each are written down.

The practical read for an adopter is that this is a first party stack with a published release cadence, an open repository and a permissive licence, and that the interesting question is not whether to use MSTest but whether to move the host from VSTest to the platform. That question has a documented answer in the features list, and the answer will differ depending on how much of Visual Studio integration and how much of the existing pipeline you depend on.

Editorial conclusion

testfx suits a .NET team that wants to keep writing MSTest tests but is tired of the VSTest host, or that wants analyzers and a project SDK to keep the test project tidy, and it is a reasonable place to look for how the two halves of the stack fit together. It does not suit a team whose tests are written in another framework and who want a single runner, since the platform's value here is as an MSTest host, and it is the wrong thing to evaluate as a library because the package boundaries matter more than the repository. Verify first which packages your project actually needs, since discovery and execution live in the adapter rather than the framework, and check the supported and unsupported features document in docs/ before assuming parity with VSTest.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/testfx on GitHub
4. README
5. Releases