Quantcast
Channel: Chutzpah - A JavaScript Test Runner
Viewing all articles
Browse latest Browse all 1864

New Post: TFS build output does not have js code coverage

$
0
0
So, it has been quite a while since this thread was started, but...

I finally got to start taking a look at this. Here's what I've discovered so far.
  1. The .coverage file is a proprietary Microsoft file format. They provide you no tooling to create these files yourself. You might be able to hack something together, but I wouldn't recommend it.
  2. You can supposedly create a .coveragexml from a CoverageDS object and publish that to the build server. However, the interface that is most easily accessible for such functionality has been marked as obsolete. I'm not a big fan of using stuff that Microsoft has marked as obsolete.
  3. The actual test results that can be viewed in a build summary on the build output supposedly use backing .trx files, but I think that is not true for the newer (2012/2013) TFS servers. My main reason for such a suspicion is that I can find no .trx files on my build servers. I am using the new Visual Studio test runner, so that may work differently that traditional mstest executions.
  4. You can create a .trx file manually. There are some posts about it that I found, and you can use mstest to publish that .trx file to the build server. According to one post, even though the .trx file has the ability to reference the coverage file in it, apparently that is not how VS (and apparently TFS) finds the coverage file to load. It looks for a .coverage or .coveragexml file in a sub-folder of the "test_id" folder (where the "test_id" is the same as the one that defines the "TestRun" in the .trx file).
So it seems as though it is possible to create the necessary artifacts for really tight TFS and VS integration, but it's not easy by any stretch.
At this point, I'm thinking it might be easier to just interrogate the _chutzpah.coverage.html file and convert it into simple text for display in the build output (and potentially for determining whether code coverage percentages are good enough to be considered a successful build--which is my goal. I already have module-based code coverage minimum thresholds for each project (DLL). I was hoping to do something similar for JS tests. to that end, perhaps just getting coverage metrics output into a more readily consumable format than html might help. I have seen the _chutzpah.coverage.json file, but it does not have the actual coverage totals that are in the html file (specifically statement coverage).

Alas, I'll have to wait till some future time to look more into this,

<sigh>

Viewing all articles
Browse latest Browse all 1864

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>