Over at StackOverflow, I am horrified by people recommending PerlUnit (and its Test::Unit front end). Isn't this abandonware? It's not been seriously touched in years. Aren't companies and people which choose this technology are generally showing that they're not paying attention to latest developments in Perl? Is there something I've seriously missed here?
PerlUnit is dead. It doesn't integrate with standard Perl testing tools. I would love to see someone pick it up again so that we could make it useful, but until then, why one earth would anyone use this?
… why I wanted StackOverflow to have a strong core Perl community preserence.
Re:What's in a name?
Ovid on 2008-09-16T12:17:13
Heh
:) I do suspect that drives some of its use. I know one company here in London which interviewed me and when I asked about their testing infrastructure, they told me they used PerlUnit. That's a huge turn-off for me. If a company is that clueless, I don't wanna work for 'em.
Re:Test::Unit is dead. Long live the Test::Unit::L
jrockway on 2008-09-16T15:17:24
Then you would want Test::Class.Re:Test::Unit is dead. Long live the Test::Unit::L
Ovid on 2008-09-16T15:53:18
Test::Class is the way to go here. It also integrates with all of the standard Perl testing libraries. It doesn't look like Test::Unit::Lite does that.
Re:Test::Unit is dead. Long live the Test::Unit::L
d3xter on 2008-09-16T17:17:43
Standard Perl testing libraries have poor and ugly non-OO API. Theirs tests also don't die after failure which differs from JUnit, PerlUnit, etc.Re:Test::Unit is dead. Long live the Test::Unit::L
Adrian on 2008-09-16T17:44:45
"Standard Perl testing libraries have poor and ugly non-OO API"
"Standard" perl testing libraries are organisationally agnostic. Which is one of their great advantages. So you can write OO (if you want) with things like Test::Class, or procedurally (if you want) with plain Test::More style, or in a functional style, or... whatever...
Please go look at Test::Class - which has a very OO API
:-) "Theirs tests also don't die after failure which differs from JUnit, PerlUnit, etc"
It does differ from jUnit - not entirely sure if it's always a clear cut win however. there are sometimes advantages to seeing all of the assertion failures in a test. Depends how you write your test methods.
It's also trivial to make them error on initial failure if you want them to.
Re:Test::Unit is dead. Long live the Test::Unit::L
chromatic on 2008-09-16T18:57:43
Standard Perl testing libraries have poor and ugly non-OO API.
How does modeling
assertEqualsas a static method show evidence of good design?Re:Test::Unit is dead. Long live the Test::Unit::L
Ovid on 2008-09-16T20:23:42
Oh, it doesn't
:) It's also worth noting that Test::Unit::Lite provides virtually no diagnostic information and forces the programmer to type a heck of a lot more boilerplate with absolutely no benefit whatsoever. And we won't even talk about how incredibly primitive (read: near useless) the assertions are. At least with the static methods in jUnit, you don't have to type a bunch of useless $self-> statements or their equivalent (but it also means that there's no real way to track state).
Re:Test::Unit is dead. Long live the Test::Unit::L
Ovid on 2008-09-16T20:11:30
If you want your tests to die after failure, use Test::Most.
Re:Test::Unit is dead. Long live the Test::Unit::L
Ovid on 2008-09-16T20:16:28
I should also add that if you really want to march to a different drummer and use a piece of software that virtually no one else will touch, that's fine, but at least see if you can submit patches to it so that it can at least output TAP and integrate with standard testing tools.
Re:Test::Unit is dead. Long live the Test::Unit::L
d3xter on 2008-09-17T10:42:03
Well, yes. It means that the standard testing tool are really TAP protocol and Test::Harness module, not Test::Simple or Test::More.BTW, I'd like to see support for nested tests for TAP protocol, something like:
1..3
unit 1..2
ok PASS unit 1/1
ok PASS unit 1/2
unit 1..1
ok PASS unit 2/1
unit 1..3
ok PASS unit 3/1
not ok Something goes wrong with 3/2
ok PASS unit 3/3
It is sad that the JUnit model really can't be implemented with Perl's TAP because TAP protocol lacks of nested tests.
Re:Test::Unit is dead. Long live the Test::Unit::L
Ovid on 2008-09-17T11:16:21
Agreed. This is a serious limitation of TAP. If you'd like to push for this, sign up for the TAP IETF mailing list and we can work on getting it done.
On the other hand, the xUnit model which says "die on failure and you have no choice in the matter" doesn't fit well with TAP, either. Tough to assert a leading plan of eight tests when it dies after three and you get a second failure because you didn't complete the plan (unless you artificially fill in a bunch of useless failing tests to pad things out). The "die on failure" attitude is extremely helpful, but making it mandatory is extremely unhelpful.
Of course, it's issues like this which reinforce the need for the IETF process
:) Re:Test::Unit is dead. Long live the Test::Unit::L
Ovid on 2008-09-17T11:21:54
Why do I always remember new points after I hit submit?
Actually, if you strictly adopt jUnit, it fits TAP quite nicely. Remember that a given test method containing several asserts is actually a single test. It's different from how Perl looks at things. So let's consider the following test method (I snagged it from a tutorial):
public void testAddItem() {
Product book2 = new Product("Pragmatic Project Automation", 29.95);
cart.addItem(book2);
double expectedBalance = book1.getPrice() + book2.getPrice();
assertEquals(expectedBalance, cart.getBalance(), 0.0);
assertEquals(2, cart.getItemCount());
}You have two asserts, but actually that could come out as a single TAP line:
ok 13 - testAddItem
You could have the asserts as optional diagnostics if you like, but this could still fit nicely with TAP without strongly violating the jUnit philosophy.
Re:Test::Unit is dead. Long live the Test::Unit::L
d3xter on 2008-09-17T12:33:07
Test::Unit and Test::Unit::Lite currently work like you wrote: single TAP line for single test function. It is somewhat limited.I think it would be much useful if TAP had support for nested tests:
i.e.:
1..2
unit 1..0 testAddItem
unit OK assertEquals(0.0, 0.0)
unit OK assertEquals(2, 2)
OK testAddItem
unit 1..0 testAnotherItem
unit not OK assertEquals(1, 2)
# no more assertions in this function
not OK testAnotherItem
etc.
I think I'll join the IETF effort because in my opinion the TAP protocol is too Perl-centric and doesn't fit to other testing models, especially to xUnit philosophy. I hope it is not to late...
Re:Test::Unit is dead. Long live the Test::Unit::L
chromatic on 2008-09-17T15:36:27
Assertion numbers are like version numbers: they're meaningless except insofar as they're different from each other.
Re:Test::More's SEE ALSO
Ovid on 2008-09-16T20:12:38
I would think so since it's abandoned and doesn't play well with others, but it's his call.
Re:Test::More's SEE ALSO
schwern on 2008-09-17T02:01:47
IF ONLY YOU HAD A COMMIT BIT FOR TEST::MORE!
... get a maint bit for it, and do an incremental release which SAYS it's deprecated and recommend alternatives so that anybody using it has a migration target.
