I won’t start the discussion what’s a good percentage for code coverage and why you should care or not, but let me just say that Code Coverage results may be very welcome while testing your applications. We all know that 100% coverage for a specific application doesn’t mean that your application is fail-proof and it won’t tell you how good your unit tests are. But it may give you a nice indication of the reach of your unit tests and those results should always be combined with other metrics of your code/tests.
Recently I noticed a strange thing when setting up unit tests (including code coverage) in Team Builds for TFS2008. To run unit tests after the compilation process in the build, you basically have two options.
Now the tricky part about code coverage results, considering you have a solution with unit tests where you enabled code coverage in the testrunconfig file.
Setting up a Team Build with activating unit tests via a vsmdi file will give you the requested Code Coverage results.
On the other hand, setting up a Team Build (same solution) with enabling unit tests via a test container won’t give you the desired Code Coverage results.
Why is that?! Well, Code Coverage settings are contained in the testrunconfig file and the thing is that the vsmdi file contains a reference to this testrunconfig file (open up notepad to verify), while the test containers don’t have a link with any testrunconfig file. If you want to include a testrunconfig file to your build that will be used during the execution of the unit tests, you need to specify the RunConfigFile property in the TfsBuild.proj file so that the Code Coverage settings are picked up during the run of the unit tests.