perlunit-devel

[Perlunit-devel] XML Generating Test Runner

[Andrew E. <an...@an...>]

Hi All,

I've written a Test::Unit::Runner subclass that writes XML reports in
the format used by JUnit, to allow Test::Unit to work with continuous
integration systems such as CruiseControl[1] and damagecontrol[2].
Does anybody have any issues with me uploading it to CPAN under the
Test::Unit namespace as Test::Unit::Runner::XML?

Thanks,

[1] http://cruisecontrol.sourceforge.net/
[2] http://damagecontrol.codehaus.org/

  -- Andrew Eland (http://www.andreweland.org)

Re: [Perlunit-devel] XML Generating Test Runner

[Matthew A. <mc...@us...>]

(While I'm posting - sorry I've been quiet for so long.  I'm writing
tested perl again now, and the mca-gdl username is something of a
misnomer 'cos I work somewhere else now.)

On Mon, Aug 23, 2004 at 02:57:19PM +0100, Andrew Eland wrote:

> I've written a Test::Unit::Runner subclass that writes XML reports in
> the format used by JUnit, to allow Test::Unit to work with continuous
> integration systems such as CruiseControl[1] and damagecontrol[2].

That's a neat trick.  I've used CruiseControl a little.  I was hoping
damagecontrol might be something similar in Perl, but it's Java too.

The obvious searches on perlmonks.org, cpan.org and Google don't turn
up any Perl continuous integration programs - anyone know of one?  I
know the Java ones can kick off a set of Perl tests, but which Perl
CGI user wants to set up Tomcat?  8-/

But I digress.

> Does anybody have any issues with me uploading it to CPAN under the
> Test::Unit namespace as Test::Unit::Runner::XML?

I don't know what the arrangements are for "ownership" of namespace.
My guess is that we manage it the way we share seats on trains.

An independent upload to CPAN must be a reasonable thing to do if the
perlunit project can't accommodate you in more useful way.

It might turn out to be less effort overall, and more useful in terms
of getting your code distributed
(e.g. http://packages.debian.org/libtest-unit-perl ), if you add your
runner to the perlunit project itself.  Would you want to do this?
What are the dependencies?  Is it just the one class or are there a
lot of support files to help with the integration side?


I've piped up quick so you don't get the full silence treatment.  I
don't know whether Adam or Piers are still around?  This list has been
quiet for a while, but I would still consider them to be in the
driving seat.

Thanks for dropping in,


Matthew  #8-)

Re: [Perlunit-devel] XML Generating Test Runner

[Andrew E. <an...@an...>]

Matthew Astley wrote:

Hi Matthew,

> I was hoping damagecontrol might be something similar in Perl, but 
 > it's Java too.
> The obvious searches on perlmonks.org, cpan.org and Google don't turn
> up any Perl continuous integration programs - anyone know of one?  I
> know the Java ones can kick off a set of Perl tests, but which Perl
> CGI user wants to set up Tomcat?  8-/

damagecontrol positions itself as a cross language continuous 
integration platform, and it's actually written in Ruby. It simply 
checks a module out of CVS (or Subversion), and then runs an arbitary 
command in checked out copy, so it's very easy to set it up for a Perl 
project. It's not very mature yet, but certainly usable.

> It might turn out to be less effort overall, and more useful in terms
> of getting your code distributed
> (e.g. http://packages.debian.org/libtest-unit-perl ), if you add your
> runner to the perlunit project itself.  Would you want to do this?
> What are the dependencies?  Is it just the one class or are there a
> lot of support files to help with the integration side?

The runner's just a single module. It depends on Time::HiRes, 
XML::Generator, and XML::XPath for the tests. XML::XPath's quite 
heavyweight, but I guess most people using Test::Unit will have it 
installed anyway. I'm happy for it to be part of Test::Unit proper, it 
seems the easiest way to go, if you don't mind the extra dependencies 
that is.

If anybody wants to look, you can grab the code from:
http://www.andreweland.org/Test-Unit-Runner-Xml-0.1.tar.gz

   -- Andrew (http://www.andreweland.org)

Re: [Perlunit-devel] XML Generating Test Runner

[Matthew A. <mc...@us...>]

On Tue, Aug 24, 2004 at 11:27:04AM +0100, Andrew Eland wrote:
> Matthew Astley wrote:

> >I was hoping damagecontrol might be something similar in Perl, but 
> >it's Java too.

Sorry, I don't know what made me think that.  Maybe something about
the look+feel?  But the install docs are at
http://damagecontrol.codehaus.org/Installing and they do mention Ruby
explicitly.

> damagecontrol positions itself as a cross language continuous
> integration platform, and it's actually written in Ruby. [...]

The install procedure sounds simple enough.  /me wonders whether Ruby
is installed at work...


> The runner's just a single module.

...and if the dependencies aren't met, it's not the end of the world?

I guess the selftests would fail, and this can be inconvenient for
installers (bug has been filed by Dave for t/try_examples.t).

I suspect CPAN packages don't support recommended dependencies, but I
haven't looked into that.

> It depends on Time::HiRes, 

I'm now quite fond of using this when it's available and falling back
on plain time() when it isn't, but it depends what you're up to.

> XML::Generator, and XML::XPath for the tests. XML::XPath's quite
> heavyweight, but I guess most people using Test::Unit will have it
> installed anyway.

Exactly.

> I'm happy for it to be part of Test::Unit proper, it seems the
> easiest way to go, if you don't mind the extra dependencies that is.
> 
> If anybody wants to look, you can grab the code from:
> http://www.andreweland.org/Test-Unit-Runner-Xml-0.1.tar.gz

Being part of: the "under the same terms as Perl itself" should be
sufficient.

I've unpacked it, will try to grab a roundtuit this weekend.


Apart from the trying it out, other things to do would be

- talk about it (if people turn up for talking)
- commit it (nice and easy)
- put the tests somewhere they won't break an install (probably a few
  hours hacking about)
- fix enough outstanding bugs to quiet the clamour of the users (!)
  (probably more talking required)
- make a release...  requires Piers' cooperation?


Andrew, are you keen to see your code release ASAP or is it just a
"make it available and people might find it handy" distribution?


Matthew  #8-)

Re: [Perlunit-devel] XML Generating Test Runner

[Andrew E. <an...@an...>]

Matthew Astley wrote:

> ...and if the dependencies aren't met, it's not the end of the world?
> 
> I guess the selftests would fail, and this can be inconvenient for
> installers (bug has been filed by Dave for t/try_examples.t).

We can just check for the presence of the XML releated modules, and skip 
the tests if they're not installed.

> I suspect CPAN packages don't support recommended dependencies, but I
> haven't looked into that.

No, I don't think it does either. But we could just not list the XML 
modules as dependencies, then die with something like "Install 
XML::Generator to use Test::Unit::Runner::XML" if the module's used with 
XML::Generator being installed.

>>It depends on Time::HiRes, 
> I'm now quite fond of using this when it's available and falling back
> on plain time() when it isn't, but it depends what you're up to.

I think it's worth leaving this dependency in, since Time::HiRes is such 
a frequently used module. Falling back to time() probably won't help 
much, since it's rare for a single unit test to run for more than a 
second. The elapsed time for each test would just be 0.

> - talk about it (if people turn up for talking)
> - commit it (nice and easy)
> - put the tests somewhere they won't break an install (probably a few
>   hours hacking about)
> - fix enough outstanding bugs to quiet the clamour of the users (!)
>   (probably more talking required)
> - make a release...  requires Piers' cooperation?

Sounds like a plan to me.

> Andrew, are you keen to see your code release ASAP or is it just a
> "make it available and people might find it handy" distribution?

I've got no reason to have the code released ASAP, I think it would be 
better to try to work it in to a proper release of Test::Unit itself. 
The tarball I linked to is purely for any interested readers of the list 
to look at.

If you're happy with the handling of dependencies described above, I'll 
implement it.

   -- Andrew (http://www.andreweland.org)