I have a unit test suite using mstest that I can run fine frome inside visual studio, but when my deploy scripts tries to run the tests using a command line call to mstest it will freeze during a test half the time. It is likely a problem in the test, but without being able to reproduce the issue inside a debugger I have been unable to find the issue.
So far I have been unable to attach the mstest process to be able to debug the issue, as when I attach and pause I see nothing in visual studio (no threads listed, no known code). Is there something odd about how it uses appdomains that prevents easily attaching to it? Any other good ways to try and troubleshoot, is it even possible to do the equivalent of Console WriteLine from inside the test so that mstest will display it in the console window its running in?
MSTest utility. To access the MSTest tool, add the Visual Studio install directory to the path or open the Visual Studio Group from the Start menu, and then open the Tools section to access the Visual Studio command prompt. Use the command MSTest from the command prompt.
To start debugging: In the Visual Studio editor, set a breakpoint in one or more test methods that you want to debug. Because test methods can run in any order, set breakpoints in all the test methods that you want to debug. In Test Explorer, select the test method(s) and then choose Debug on the right-click menu.
Two options.
or
Run mstest with the /noisolation switch. It will execute the tests directly rather than spawning a helper process.
Mixed: Automatically attach the VS debugger to the command line mstest.exe:
I configure the Debug tab for my test project with the following:
Start External Program: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe
Command line arguments: /noisolation /testcontainer:MyProjectName.dll
After looking at the process tree in Process Explorer, MSTest.exe
was launching a child process named QTAgent32_40.exe
, I was able to attach to that process and turn off Just my code so that I could debug my tests.
Turns out it was effectively deadlocking inside a mock object I created that was using MethodImplOptions.Synchronized
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With