If you've used any of the VSTS Developer Edition builds you know that the integrated unit testing and code coverage is pretty sweet. But what if you wanted to use those tools as part of an automated build process that's not part of Team Foundation Server? Luckily the integrated tool, named MSTest, has a command-line interface.

There are a few different ways to use MSTest from the command line, but I'm only going to show how you use it when your unit tests are in a separate testing project (which in my opinion should always be the case). So assuming you've got those and have created some tests (and compiled of course), all you have to do is this:

1. Open the Visual Studio 2005 Command Prompt. Navigate to your solution folder.
2. At the command prompt type something that follows this format:
   mstest /testcontainer:[TestProjectDir]\bin\debug\[TestProjectAssembly]
   
   For instance, you might have something like this: mstest /testcontainer:BankAccountTest\bin\debug\BankAccountTest.dll

Once you hit enter you'll see MSTest start to execute the tests, and it will show you which tests passed or failed and give you a summary of how many tests passed/failed. It will also tell you what file it stored the test results in.

The key to all this is the /testcontainer flag. MSTest exposes other flags such as /testmetadata, /test, and /testlist, but I won't go into all of those here (maybe at a later time). What's important to know is that /testcontainer tells MSTest that the assembly you gave it contains all the tests it needs to execute.

The test results file has an extension of .trx and is given a default name in this format: “UserName_MachineName Year-Month-Day Hour_Minutes_Seconds.trx (the hour being in military time). For instance, a recent test results file of mine is named “David_ARCWARE1 2005-09-25 21_22_48.trx“. All test resuts files are simply text files, so you can view them in any plain old text editor. However, if you double-click a .trx file it will open in an instance of VSTS, thus allowing you to view the test results as if you had executed the tests in your VSTS instance. That's nice because in an automated build process I can grab any test results file from the central build machine and view them locally in my instance of VSTS.

However, at this point, if I open a test results file in VSTS and go to view code coverage results, I get the message “Code coverage is not enabled for this test run“. So how can you run VSTS code coverage from the command line? After all, in a continuous integration environment, running code coverage all the time is very important. Never fear, MSTest can do that as well. All you have to do is make some simple configuration changes. Follow these steps to enable code coverage and run it with MSTest:

1. In your Visual Studio solution, you should have a Solution Items folder. In this folder, you should see a file named localtestrun.testrunconfig. Open it.
2. On the left, click the Code Coverage option.
3. Under Artifacts to instrument, select your code assembly and its corresponding test assembly.
4. Click Apply then click Close.
5. Open the Visual Studio 2005 Command Prompt. Navigate to your solution folder.
6. At the command prompt type something that follows the format above, except now add this to it: /runconfig:localtestrun.testrunconfig
   For instance, you might have something like this: mstest /testcontainer:BankAccountTest\bin\debug\BankAccountTest.dll /runconfig:localtestrun.testrunconfig

Now when you hit enter you'll see MSTest load the localtestrun.testrunconfig file before it starts executing the tests. This is important because that file is where you enabled code coverage for your code and test assemblies. Therefore, you can open the test results file in your instance of VSTS and now see the code coverage results, with all the pretty formatting and statistics that VSTS provides.

One last thing. If you don't like the default name given to each of your test results files, you can easily change it by using the /resultsfile command line option or by changing the setting in the localtestrun.testrunconfig file (under General settings).

Similar Posts

1. Using svn:externals to Manage Project References
2. Compare Assemblies with BitDiffer
3. Decreasing Developer Ramp Up Time