in reply to Re: Unit Testing in Perl
in thread Unit Testing in Perl

Yes, I was gradually getting the impression that using Test::Unit might be a mistake, even though at first glance it seems like the natural choice if you are xUnit inclined. Does the fact that it neglects to base it itself on Test::Builder mean that it does not play nicely with the stadard testing phase of CPAN style module distributions? If Test::Unit seemed reasonably close to what I wanted, what is the closest thing that behaves in an appropriately Perlish fashion?

Replies are listed 'Best First'.
Re^3: Unit Testing in Perl
by eyepopslikeamosquito (Archbishop) on Jun 26, 2005 at 12:52 UTC

    Does the fact that it neglects to base it itself on Test::Builder mean that it does not play nicely with the standard testing phase of CPAN style module distributions?
    Not being based on Test::Builder makes it difficult to extend or integrate with other CPAN testing modules. See the excellent documentation that comes with Test::Class for more details.

    If Test::Unit seemed reasonably close to what I wanted, what is the closest thing that behaves in an appropriately Perlish fashion?
    Test::Class. However, don't forget plain ol' Test::More in cases where Test::Class may be overkill.

Re^3: Unit Testing in Perl
by adrianh (Chancellor) on Jun 27, 2005 at 01:11 UTC
    Does the fact that it neglects to base it itself on Test::Builder mean that it does not play nicely with the stadard testing phase of CPAN style module distributions?

    Yes and no.

    T::U can be made to output TAP (using Test::Unit::HarnessUnit) which means Test::Harness can understand it's output, so you can integrate it into the normal CPAN testing phase.

    This disadvantages are that:

    • It doesn't support all of TAP - so you cannot use things like SKIP and TODO tests if you want to
    • Since it is not based on Test::Builder it doesn't integrate with all of the other Test::Builder based modules on CPAN - so you may end up reinventing some existing wheels
    • Since it's not a core module (unlike Test::More) you have an extra dependency to install.

    Well - that and the fact that its huge, overcomplicated and pretty much unmaintained :-)

    If Test::Unit seemed reasonably close to what I wanted, what is the closest thing that behaves in an appropriately Perlish fashion?

    Test::Class - but I would say that :-)

Re^3: Unit Testing in Perl
by adamk (Chaplain) on Jun 26, 2005 at 16:02 UTC
    If Test::Unit does what you want, but sucks, then perhaps you could consider taking it over, upgrading it to use Test::More or some other TAP-based module, and improving it as you see fit?
      If Test::Unit does what you want, but sucks, then perhaps you could consider taking it over, upgrading it to use Test::More or some other TAP-based module, and improving it as you see fit?

      As pointed out earlier I've already volunteered for this. I did get around to mailing the maintainers and never got a reply. I should really chase it up.

        Goodo!

        Protocol is generally that you mail a couple of times over a couple of weeks, and try any other "reasonable" way you can think of to contact them. (google for other non-stale email addresses if this is the case, etc).

        If the author is persona non grata, then write to the modules@ mailing list and ask to take over the module. You will be added to the authors for the module, then patch the existing version as you see fit and upload.