No code coverage results on TFS 2013 Build Server

4
votes

So our TFS 2013 builds do everything correctly except report code coverage. I've seen similar questions here, e.g. TFS 2013 - No Code Coverage Results, but we've already tried the suggested fixes with no results.

UPDATE 1 — we've taken more steps to try to resolve this; here's the complete list:

  • Ensured Visual Studio Ultimate was installed on the build server
  • Tried setting the build definition's "CodeCoverageEnabled" to true as well as the "Code coverage is enabled" setting
  • Ensured the build was using the Debug configuration and that PDBs were being generated for the DLLs to be tested
  • Added a .runsettings file with the correct ModulePath included under <CodeCoverage> (verified in build log that the module path was being interpreted correctly; it would produce errors if we intentionally malformed it)
  • Checked in .runsettings file
  • Set build definition to "Custom" and pointed to .runsettings file

The build process itself works fine. We can get code coverage results when we build the project locally in the IDE. On the build server, both MSTest and NUnit test projects run fine, and we see pass/fail results as expected. The "No Code Coverage Results" message still plagues us though.

Update 2 - Here is what we see in the run log: Build log test run output

Somebody suggested homegrown code-coverage calculator in https://stackoverflow.com/a/16198120/141508, but it'd be a crime to spend $150 bazillion-thousand dollars on TFS 2013 & VS Ultimate 2013 with MSDN and still not have this one basic function working.

4
visual-studiotfscode-coveragebuild-server

4 Answers

3
votes

Add a run settings file to source control. Set the tests to custom and point to the run settings file. More info on using the .runsettings file can be found on msdn: http://msdn.microsoft.com/en-us/library/jj159530.aspx

1
votes

I was experiencing the same problem. My issue was with the ModulePath. The MSDN examples suggest you can just use the name of a target binary. That was not working for me. However, when I made the name a regular expression, it worked. I am also dumping build output into one folder so that pdb and other reference files are found. Hope that helps.

<ModulePath>.*Administration\.dll.*</ModulePath>
1
votes

I am using local build server with Visual Studio online with a .runsettings file and I had exactly the same issue.

None of the trickery above helped, so I tested the build script on the hosted build controller and it worked fine, so I decided the problem must be the build server itself.

I changed the Build Service account from "Network Service" to a regular windows user account in the TFS Configuration Tool and now code coverage is collected. Note that this user will need access to the TFS build directories.

0
votes

I found this question because I saw something peculiar on this article. (Look for the "Delay" setting that defaults to 60).

d. Add a new argument ‘Delay’, enter details as mentioned below Name – Delay, Direction – In, ArgumentType-Int32, Default Value – 60 This argument is required to delay coverage check, so that required build details are filled up by the build agent, this delay varies from system to system, in some cases this might not be required at all.

http://www.prowareness.com/blog/failing-build-on-insufficient-code-coverageblock-coverage-part-3/

Maybe try putting in a "delay" work-flow item in the template you are using.......