There was a comment on an internal mailing list yesterday about *.vsmdi files as an example of “why you shouldn’t use MSTest”. Before I jump right in and agree with the author of that statement it might be worth examining what a *.vsmdi file is, and its place in the overall plumbing of MSTest.
The *.vsmdi file (MSTestContrib.vsmdi in my example) contains a list of tests which exist across all projects within your solution. Double-clicking on the *.vsmdi file inside Visual Studio will launch the “Test List Editor” which allows you to organise these tests into a hierarchy which you can then use to selectively execute tests.
When Visual Studio 2005 shipped Microsoft assumed that most people would use this view to arrange which tests they wanted to run and that it would be particularly useful when you had a large number of tests.
Fast forward to Visual Studio 2010 and the reality is somewhat different. Most developers who are using MSTest simply use the Test View window to control which tests they want to run, and in almost all cases they run all of the tests (because that is what a good TDD developer would do). The *.vsmdi file is really just a relic of a poor assumption about how Visual Studio was going to be used.
Originally the use of the *.vsmdi file was a requirement to get MSTest integration with MSBuild working on a TFS build server, however this requirement has since been removed once again removing the utility of the file.
To top it off, Visual Studio 2010 now includes features which make it possible to better target their test execution effort (if they do have a very large number of tests) by using the “Impacted Tests” view. This view relies on code coverage and test impact data to interactively suggest which tests you should run based on the changes you have made since your last test execution. So the *.vsmdi file is now largely redundant.
So what, why should I care about the *.vsmdi file?
Unfortunately the *.vsmdi file, as well as being redundant has always had some issues around version control and read-only flags which is ironic given that they are part of the Team Foundation Server tool-chain. The screenshot on the right shows an all too common scenario where due to either file locks or some other mysterious issue, multiple *.vsmdi files are being generated. It seems to happen most when developers are working together on a project and frequently adding tests.
Assuming that you are just using the Test View to run your tests these files are perfectly safe to delete. If you want to try and tackle the problem, there is an imperfect solution. Simply remove all the files from your disk and in version control (assuming you are using TFS here, or any version control system that is integrated with Visual Studio), then instruct the version control system to perform an exclusive check-out.
Like I said, it’s not a perfect solution, especially for agile development teams, but it will stop those annoying file1.vsmdi, file2.vsmdi … file20.vsmdi scenarios coming up.
Is this a good reason not to use MSTest?
I’d say it is a pretty weak argument by itself. Most people have a preference from one unit testing framework over an other. Some people prefer xUnit over NUnit, others prefer MbUnit. Every unit testing framework has its benefits as well as its quirks but people seem to point frequently to MSTest as a commonly despised testing framework.
Personally I like it – even with its faults, its a personal preference. Am I lesser developer because I use MSTest? I don’t like to think so. I enjoy some of the out-of-the-box integrated capabilities such as Impacted tests, and the data collectors as well as good integration with Team Foundation Server and Lab Management. Everyone is entitled to their own opinion though!