Issue #8 resolved

Junit-compatible XML output

Kamil Kisiel
created an issue

I have another patch for cram which adds JUnit-compatible XML output for the test results. The resulting XML file can be read in to a continuous integration system such as Hudson or Bitten to record the test results.

The patch is available at https://bitbucket.org/kisielk/cram-mq/src/tip/xml_report

I'm not sure if I've got a feel for your coding style yet, so perhaps the implementation isn't how you would prefer but I've tried to keep it to the spirit of the existing code.

I imagine it would be somewhat cleaner with the use of some OO concepts for the test runner, but I didn't want to undertake any major refactoring.

As for testing, so far I've only update the existing test to check for the --xml option in the --help string.

Comments (5)

  1. Brodie Rao staff repo owner
    • changed status to open

    Is there any reason we need --xml to take a filename parameter? Would it be fine if it just printed XML output to stdout?

    I'm not sure how I feel about embedding the XML functionality within the main test runner. I think we should probably change its output/return value to something that's easy to serialize into many different formats.

    If you have any other suggestions for refactoring, feel free to make a followup patch. As for OO concepts, I generally stay away from using classes unless I need to encode state or I could make use of inheritance.

  2. Kamil Kisiel reporter

    I tried to make the --xml option similar to the nose switch --with-xunit, although that one writes to a fixed filename which I am not too keen on. The reason I would prefer not to write to stdout is because the standard test output is also useful even when running in a CI environment. Most CI tools provide a live console to let you monitor a build, and it's nice to see the same output you'd get when running it on your dev machine.

    If the XML output just went to stdout, you'd have to redirect it to a file and then you'd get not live output on your progress. You could still use something like tee, but it's a bit more complicated.

    I agree that embedding the XML functionality in the runner is probably not the best way to do it. I'd be happy to change the semantics of run() to support different output types. Maybe we could discuss where we want to go with that on IRC sometime?

  3. Brodie Rao staff repo owner

    IM is probably the best way to get a hold of me. My Google Talk/Jabber account is the same email address I use in my commits.

    I've also created #cram on freenode if you prefer IRC. I don't pay attention to IRC nearly as much as IM, though.

  4. Brodie Rao staff repo owner

    Sorry about leaving this issue languishing. I've finally gotten around to addressing this in 2a4c52a.

    I've done quite a bit of refactoring to Cram to add this in what I think is a clean way: there's an internal test runner now and a pipeline of output generators (one being the CLI and the other being the xUnit generator).

    If you get a chance, try it out and let me know how it goes. I've tested it with Bamboo and it seems to work okay.

  5. Log in to comment