TFS and code coverage for web application (MVC) assemblies not working

Question

I've got an MVC web application with associated controller tests that run under a TFS build as per normal.

I can see the tests running and passing in the build log and they appear in the "Result details for Any CPU/Release" section of the build

I also have a number of other assemblies with associated tests that are running in the same build. Tests are passing and the details are being shown in the results and logs just fine.

I've enabled code coverage in the build script and the testrunconfig.
The coverage is appearing for all assemblies EXCEPT the web application even though it looks like the tests have been run for it.

Is there anything obvious that I have missed or some sort of work around that I need to do? I've searched around for a while and haven't found an answer.

Has anyone got code coverage working for MVC web applications using TFS?

Answer 1

Following looks a pretty detailed hack:

http://blogs.blackmarble.co.uk/blogs/rfennell/archive/2009/04/15/team-build-code-coverage-and-mvc.aspx

Answer 2

After reading the article posted earlier I thought I would try an alternate approach.

looking at the localrun.testconfig in a text editor I saw that the assemblies that contained code coverage data were in the section below

<Regular> <CodeCoverageItem ... /> <CodeCoverageItem ... /> </Regular>

The only reference to a web project was in the section:

<AspNet> <AspNetCodeCoverageItem id="..." name="..." applicationRoot="/" url="http://localhost:0/" /> </AspNet>

So to get code coverage working in TFS:
In VS IDE, double click the localrun.testconfig, then click Code Coverage and then manually add the MVC assembly by clicking the Add Assembly... button. You will get a warning message about duplicate assemblies, tell it to use this new file.

What this does behind the scenes in the localrun.testconfig is add a CodeCoverageItem entry with the MVC assembly and removes the AspNet section from the CodeCoverage section of the file.

This has the added benefit of not starting up a local web server every time you run your tests.

But it may have a detrimental effect on any Watin type tests and coverage.