|
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? |
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.
| [reply] |
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 :-)
| [reply] |
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?
| [reply] |
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
|
