converting TAP output to JUnit-style XML

Here’s a perl script that may prove useful: tap-to-junit-xml

NAME

tap-to-junit-xml – convert perl-style TAP test output to JUnit-style XML

SYNOPSIS

tap-to-junit-xml "test suite name" [ outputprefix ] < tap_output.log

DESCRIPTION

Parse test suite output in TAP (Test Anything Protocol) format, and produce XML output in a similar format to that produced by the <junit> ant task. This is useful for consumption by continuous-integration systems like Hudson.

Written in perl, requires TAP::Parser and XML::Generator. It's based on junit_xml.pl by Matisse Enzer, although pretty much entirely rewritten.

This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

11 Comments

  1. Pavel Topinka
    Posted April 9, 2008 at 08:49 | Permalink

    Hello I tried this script and it works fine. I have question about integration with Hudson. How can hudson realize that test fails ? Do you run your perl test from ANT? Thank you Pavel

  2. Posted April 9, 2008 at 09:19 | Permalink

    In my Hudson configuration, I run the perl tests like this:

        make test TEST_VERBOSE=1 2>&1 | tee make_test.log
        tap-to-junit-xml "make test" testxml/make_test < make_test.log
    

    And then I have Hudson set up to read the JUnit-formatted XML from "testxml/**.xml".

  3. Posted May 26, 2008 at 18:20 | Permalink

    Cool. I just saw this post, and added a link to it on my original post of the script that you re-wrote.

    FYI: These days I’ve been using buildbot (http://buildbot.net/trac) for continuous integration (because other teams were already using it) and it is an interesting platform to look at: While no where near as mature as CruiseControl buildbot is specifically designed for distributed use – that is, you set up a single master which watches your commits, and then sends build jobs to many slaves – which can be on many different machines, so you can test continuous integration on multiple platforms.

  4. Posted May 26, 2008 at 21:14 | Permalink

    Thanks for the comment Matisse!

    Actually, we moved from buildbot in SpamAssassin, to Hudson, mainly because (a) we didn’t need the advanced distribution stuff; (b) we were having problems with it dealing with NAT, dynamic IPs and firewalls anyway; and (c) Hudson has a much nicer web UI. in my opinion ;)

  5. Posted May 27, 2008 at 16:24 | Permalink

    I hadn’t heard of Hudson before this, so I’m glad to learn about another tool. Maybe you or someone would like to add Hudson to this Continuous Integration Feature Matrix: http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix which compares over a dozen continuous integration systems.

  6. Posted May 27, 2008 at 16:26 | Permalink

    Oops – I see Hudson is already on that page – somehow I missed it when I looked a few moments ago.

  7. xaos
    Posted June 11, 2008 at 01:30 | Permalink

    Can we get some explanatory notes on how to integrate and use this? I am currently using test::tap::htmlmatrix and want to give this a shot. I already have test cases saved as perl files that I am calling via an array @TestFiles.

  8. Posted June 11, 2008 at 12:25 | Permalink

    xaos: simply run the tests in verbose mode and pass the full TAP output (both stdout and stderr) to the script.

  9. xaos
    Posted June 12, 2008 at 01:22 | Permalink

    Thanks, that worked! Now if I just had the correct style sheet so that it displayed correctly I would be golden.

  10. Posted January 16, 2009 at 13:28 | Permalink

    You may want to have a look a TAP::Harness::JUnit for another solution for producing JUnit output from Perl tests. In fact is was partly inspired by this.

    http://search.cpan.org/dist/TAP-Harness-JUnit/

  11. Posted January 16, 2009 at 13:53 | Permalink

    Lubomir — thanks, that looks interesting! feel free to cut and paste code if you like ;)