DayPath Journal

Songhay Studio: It’s No Longer about MSTEST.EXE; it’s vstest.console.exe…

Yes, I feel like I’m the only one in the world (outside of Redmond) using the default testing tools shipping with Visual Studio. So it should be no surprise to not even notice that MSTEST.EXE is no longer recommended—this is the new deal:

"%ProgramFiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe"
    

Also there is an “enable code coverage” option I have not tried out yet:

vstest.console.exe EnableCodeCoverage

Related Links

MSTest.exe Command-Line Options

“For example, for ordered tests, the test container is the .orderedtest file that defines the ordered test. For unit tests, it is the assembly built from the test project that contains the unit test source files.”

Using VSTest.Console from the Command Line

“You can use the VSTest.Console.exe program to run automated unit and coded UI tests from a command line. VSTest.Console.exe is optimized for performance and is used in place of MSTest.exe in Visual Studio 2012.”

New Unit Test functionality in VS2012 Update 2: Test Playlist

Do not confuse a “playlist” with an “ordered test”—it feels like “playlist” tests must be ‘true’ unit tests (no dependencies on other tests).

How to manage unit tests in Visual Studio 2012 Update 1: Part 1–Using Traits in the Unit Test Explorer

“Traits are not only useful as a grouping mechanism in the Test Explorer, it also part of what can control which tests you run. This has been a big request—because it means the developer can focus on the tests relevant to the work, and not be bothered with running other, perhaps long-running tests, which would otherwise slow down the whole development experience.”

How To Unit Test Async Methods with MSTest, XUnit and VS11 Beta

MSTest finally got some love with the Visual Studio 11 Beta and one of those changes was to enable tests to run asynchronously using the async and await keywords.”

Gotchas: MSTest’s [DeploymentItem] attribute

“Essentially it seemed far too easy to create a test that worked fine on the local developer’s machine and failed either on the CI server or in someone else’s development environment. In fact 25% of our unit test related build breaks were caused by this issue and some of them took a while to track down!”