Front page | perl.qa |
Postings from October 2011
Re: Do we need subtests in TAP?
From: Michael G Schwern
October 30, 2011 20:31
Re: Do we need subtests in TAP?
Message ID: 4EAE1671.firstname.lastname@example.org
On 2011.10.30 7:21 PM, David Golden wrote:
> I haven't followed the T::B 2 work closely enough, so could I ask you
> to please step back and explain the benefits of T::B 1.5 that is worth
> stepping backwards in terms of capabilities? What I mean is that we
> have TAP::Harness now that processes subtest TAP and we have a T::B
> now that produces subtest TAP, so why stop?
I'm not advocating one side or the other just yet. I'm investigating what
subtests are used for and if they're worth the bother, because I don't use
them. Ovid always took care of them.
They're a lot of bother, but it looks like it would be even more bother to do
them without nested TAP.
The current Test::Builder implementation is a mess and its design cannot go
forward. They have to be gotten just right to ensure that not just nested TAP
is supported, but nesting in other formats. Or if those formats don't have
nesting, then linearizing the subtests in those formats. And event watcher
(ie. plugins) authors have to be shielded from the complexity.
The end result is looking to be fairly simple, but that doesn't mean a lot of
work didn't go into it.
> This quote from the TB 2 docs scares me a little: "Test::Builder2 is
> very generic and doesn't do a lot of the work you've probably come to
> expect a test framework to do. This reduction of assumptions increases
> flexibility and ensures that TB2 can remain the core of Perl testing
> for another decade to come."
> That sounds an awful lot like second system syndrome. And -- hey,
> that's great if it works -- I mean no offense is saying that. But
> something that is *half* of a second system that loses a nice feature
> of the first system seems a suboptimal outcome.
D O N ' T P A N I C
What you read is about the Test::Builder2 *class*. The class is separate from
the Test::Builder2 framework. Sorry if that's not clear. The framework can
do what Test::Builder does (with the current exception of subtests) and more.
The Test::Builder2 class does a lot less than the Test::Builder class. I
intended to provide a provide a pack of roles to add in more functionality,
and people could write more. But I'm not worrying about the Test::Builder2
class right now. Test::Builder2 is a user friendly shell to generate test
events. Much of the Test::Builder functionality has been (or will be) pushed
down into event watchers.
Test::Builder 1.5 will use that event system. The benefit is we can continue
to have a unified testing framework, but write tests using whatever interface
you like and output in whatever format you like. Plugins which effect the
whole state of the test (such as Test::NoWarnings) become safer to write and
continue to work even as testing styles become different. You can even write
your own builder.
TB2 is the opposite of the second system syndrome. The second system is
traditionally overbuilt with too many features that nobody needs. While the
event system might qualify, the Test::Builder2 class itself does not.
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army