Excluding projects from the Visual Studio Code Coverage tool

09 Sep 2013

I recently started playing with Visual Studio's code coverage analysis tool to show me where my unit testing is insufficient. I keep tests in their own projects, named after the assembly they are testing, but with ".Tests" bunged on the end.

The only problem I've discovered with this is by default the Code Coverage tool will analyse all projects in the solution including the test projects themselves, which score 0% coverage and skews your solution stats.

You can apply the [ExcludeFromCodeCoverage] attribute to every test class, and that works fine, but is a right faff with lots of tests.

The alternative is to exclude the whole assembly. Following the guide over at the MSDN suggests that you can do the following in a .runsettings file:

<ModulePaths>
  <Include>
    <!-- Include all loaded .dll assemblies (but not .exe assemblies): -->
    <ModulePath>.*\.dll$</ModulePath>
  </Include>
  <Exclude>
    <!-- But exclude some assemblies: -->
    <ModulePath>.*\Fabrikam\.MyTests1\.dll$</ModulePath>
    <!-- Exclude all file paths that contain "Temp": -->
    <ModulePath>.*Temp.*</ModulePath> 
  </Exclude>
</ModulePaths>

So full of enthusiasm I tried this:

<ModulePaths>
  <Exclude>
    <ModulePath>.*tests.*</ModulePath>
    <ModulePath>.*Tests.*</ModulePath>
  </Exclude>
</ModulePaths>

But instead of basking in the glory of a 100% code coverage score, I get the following error:

Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see http://go.microsoft.com/fwlink/?LinkID=253731

It turns out the regular expression parser is being confused by the non-escaped dots (cheers Grin), so I need to do this instead.

<ModulePaths>
  <Exclude>
    <ModulePath>.*\.tests\..*</ModulePath>
    <ModulePath>.*\.Tests\..*</ModulePath>
  </Exclude>
</ModulePaths>

This had me stumped for a while, but I'm glad it's fixed. I think the MSDN page needs updating. Anyway, back to writing unit tests :)