MSTest VS vstest

This library extends the traditional assertions provided by frameworks like MSTest, NUnit, or XUnit by offering a more extensive set of extension methods. Fluent Assertions supports a wide range of types like collections, strings, and objects and even allows for more advanced assertions like throwing exceptions.

Use a testing framework: Utilize a testing framework like NUnit, xUnit, or MSTest to create, organize, and run your tests. These frameworks provide a consistent way to write tests, generate test reports, and integrate with continuous integration tools.

Release v2.2.9 · microsoft/testfx (github.com)

Which exact version of the MSTest packages are you using? Currently it should be MSTest.TestFramework 2.2.7.

Versão Atual 16.11.0 Downloads 252.3M Site https://github.com/microsoft/testfx

MSTest is the default test framework that is shipped along with Visual Studio. The initial version of MSTest (V1) was not open-source; however, MSTest V2 is open-source. The project is hosted on GitHub. Like other test frameworks, it can also be used for data driven testing. You can download MSTest V2 from Nuget.org.

Open-Source – MSTest V2 is open-source, and the project is hosted on GitHub. The public repositories of the MSTest V2 are Microsoft/testfx and Microsoft/testfx-docs. Since the project is open-source, it allows contributions from the community.

Another commenter in your first post linked you to a bug report. The original bug was a sporadic one with dotnet test. But commenters added more reliable cases, and cases for other dotnet commands.

However, I am hesitant to do so. Whenever it seems I have to fight the tools that are provided for me this is a likely sign that I’m Doing Things Wrong because of some fundamental misunderstandings and misassumptions on my part. I did some digging and found that VSTest by design forces the placement of data collectors’ output into GUIDed subdirectories, see Coverlet documentation, Coverlet issue #500 and VSTest issue #2378. That this is forced by design reinforces my worries that I’m doing something counterproductive.

I've had success creating my own logger by following this guide on the vsdocs github. Nowadays you don't have to deploy the assemblies for the custom logger to the vs install folders. vstest will scan the build output directory for assemblies that match the specified pattern, *.testlogger.dll. You can also specify the path for custom test adapters either from the command line or a runsettings file using the TestAdapterPath option (this is only available since v15.1 but you mentioned you've tried the html logger and I think that's much newer than v15.1). If you get stuck with the implementation you can try referring to vstest's own loggers: htmllogger, trxlogger.

IMO it's just held back by its ecosystem. NuGet doesn't integrate nearly as well with library source as Maven/Gradle/etc, and stuff like this makes it feel like a second-class citizen for CI.

But going to have to dig in deep tonight, it seems that answer to what I seek is probably hidden somewhere in this repo: https://github.com/microsoft/vstest/ and the ITestDiscovery discovery process.