Converting a FlexCover CVR to Cobertura XML report
Brian LeGros | October 19th, 2009 | programmingIf you’re using FlexCover as a code coverage tool within your Flex build process, the resulting report will be an XML file with a .cvr file extension. Currently there are no FlexCover plugins for the popular CI servers (i.e. – Hudson, Cruise Control, Bamboo, etc), so to take advantage of the cool baked-in reporting for code coverage, an XML report for a supported report format (e.g. – Emma, Cobertura, Clover) is needed. Currently Paul over at eyefodder has a solution using a custom build of the CoverageViewer and CoverageAgent which will produce an Emma formatted report.
Instead of creating my own custom build of FlexCover, I decided to work on an XSL transformation to the Cobertura XML report format to see if I could have any success. After a pain-staking journey back into the world of XSL, I was able to throw together an XSLT that is working with Hudson’s Cobertura plugin. You can find the XSLT under FlexUnit4 source control @ http://opensource.adobe.com/svn/opensource/flexunit/branches/4.x/FlexUnit4Test/fc-to-cobertura.xsl. If you’d like to see the reports generated for Hudson in action, check out http://flexunit.digitalprimates.net/view/Flex%203.2/job/FlexUnit4-Flex3.2/cobertura/. We currently only have the builds using Flex SDK 3.2 running with FlexCover since the latest version of FlexCover (0.81) only supports versions 3.0 and 3.2 of the SDK. Looks like some work has been done to integrate with Flex 4.0, so as support is added to FlexCover, I’ll add that work into the FlexUnit4 CI builds.
To use this XSLT to transform the CVR file, make sure you are using an XSLT 2.0 compatible engine (e.g. – Saxon) with your build tool of choice. Additionally, you will need to provide three paramaters to the stylesheet for it to work correctly:
- sourcePath – A comma delimited list of absolute paths to the source directories, each excluding a trailing slash, for which the instrumented SWC/SWF was created.
- version – The version number of FlexCover you used to generate the CVR file.
- timestamp – The date/time in which the transformation occurred in ms from epoch. I’m using a date format of “MM/DD/yyyy HH:mm:ss.SSS’ and I’m not having any issues, but it may be ignored by the Hudson plugin.
If anyone has any suggestions on rewriting the XSLT using XSL 1.0 instead of 2.0, please let me know, I’m definitely open to refactoring it. Thus far the results look fairly consistent with a Cobertura XML report and integration with Hudson’s Cobertura plugin is working out great. Hope this helps those who are trying to tackle the FlexCover CI integration problem.
Tags: bamboo, cobertura, code coverage, cruise control, emma, flexcover, flexunit, hudson, xml, xunit
Discussion
October 27th, 2009 at 1:00 pm
This is the thing that I wait for long since I check out FlexUnit4 nightly build.
I just apply your build script in my project and it work well and perfect.
Thank a lot for great work.
September 20th, 2010 at 10:57 pm
Brian, do you still have the working example available?
I’ve got this working in my build, but some of the cobertura metrics and links in hudson do not work.
Can you email the versions of hudson and cobertura you used?
September 21st, 2010 at 8:26 am
@Mike – I haven’t had much luck getting FlexCover to work recently with my builds, but I know the XSLT works since we used it on FlexUnit4 and other projects like Reflex use it. The version of Hudson should not matter since the Cobertura report format has not changed. Because of the XLST, you don’t actually have to use Cobertura, just say you have Cobertura reports and Hudson will parse them as such. If you send me the build script you’re using to do the conversion I can take a look at it.
-Brian
November 8th, 2010 at 7:43 am
Hi Brian,
I’m looking at apparat and flexunit4 to see if i’m able to create a testrunner that spits out a cobertura report. But it’s hard to find documentation on the xml format. So i was happy to find this post. Obviously you have found the specs. Unfortunately the second link is broken. Do you have any example of a generated cobertura.xml? Looking all over the web but i can only find html reports…
thanx,
Arnoud
November 8th, 2010 at 11:58 am
@Arnoud – I’m actually working to add apparat support for code coverage into the mix for release 4.2 of the FlexUnit Ant task. I’m using FlexMojos as a template and having Velo help me with questions re: the implementation. I actually kind of stuck right now at a point where Apparat won’t find my source files and doesn’t do any AVM byte-weaving for me. If you’re interested in contributing, check out my 4.2 branch on GitHub (https://github.com/blegros/flexunit/blob/4.2/FlexUnit4AntTasks/src/org/flexunit/ant/Instrumentation.java). I think it’s up to date with my latest attempts.
As far as the second link, I stopped using the flexcover integration with FlexUnit4 due to issue with the CoverageViewer application. You can check out the build however on my master branch on my github fork(https://github.com/blegros/flexunit).
HTH. Let me know if you’re interested in contributing to the Ant support.
November 8th, 2010 at 3:42 pm
Hi Brian,
Great to hear that this is planned to be integrated in the ant tasks! I can imagine that it’s hard to integrate this in the core of the flexUnitAntTask system. Throwing scala in the mix doesn’t make it easier. That’s why I had planned to go the other route. As i’ve read in the apparat notes an instrumented class with a specific interface gets called by apparat with parameters and line number.
My plan was to launch adl with an input parameter that says where the output must go. My testrunner is always an air app so then i can write the results to a file. So i’d compile the extended testrunner and instrument it an let the testrunner write output. For the instrumentation i would use the ant tasks of apparat. Then i could circumvent writing any Java code…
I know this is not ideal because you have to install scala for it. I’d like to help but unfortunately the last time i wrote some real Java is about 10 years ago. Last 5 years mostly actionscript3 stuff ans sometimes a bit Blazeds. That’s why I planned to go the other route. Having the cobertura format would then be enough (if line numbers and filenames are enough) But i agree on the fact that integrating it in the flexUnitAnt tasks is much better and cleaner.
But I will check out The ant tasks of flexunit and have a look. I just cannot promise that I can deliver anything useful… I looked at the flex mojos code before but it’s hard to grasp if you’re not a maven expert. Might give that one another go too. I’ll let you know if i come up with something useful.
Arnoud
November 16th, 2010 at 10:11 am
Hi Brian,
I’m still struggling with the coverage but i think i found something you may like. I reported the next issue:
http://code.google.com/p/apparat/issues/detail?id=36
apparently only debug swf’s will be intrumented. Might be the problem you are facing.
I did look in the sources for apparat/flex mojos and flexunit ant task but i’m afraid it’s a bit too hard to grasp it all and deliver something usefull to the project in a reasonable time scale. Anyway i hope this is the problem you are facing at the moment.
Best,
Arnoud
November 16th, 2010 at 2:55 pm
@Arnoud – Thanks for digging into this for me. This is definitely something I can try to see if it helps. I think I had seen some threads on the FlexMojos mailing list saying the sources needed to be baked into the SWF as well, so I have a couple new things to try going forward. Don’t worry about the Ant and Maven stuff, they’re bigger problems in scope than just code coverage, so it’s understandable. Watch the blog for an update of when I have 4.2 working with Apparat to see if it helps any. Thanks again for the help.
December 3rd, 2010 at 6:45 am
[...] of these, I made use of the information and XSL file from Brian LeGros’ great article over on Cookies And Code. This was actually my starting point in my process of setting up Hudson, and I worked around this. [...]
Add A Comment