Subtests are the last major feature hurdle for Test::Builder 1.5. They're
kind of a hacky mess in Test::Builder 1 which I don't want to bring forward.
A subtest has to
1) create a separate state of the test
2) change the format of the output
3) communicate the result of the test back to the parent
Currently this is done by
1) copying the existing TB singleton
2) creating a new TB object set to indent the output
3) jamming it in place of the TB singleton
4) running the subtests
5) restoring the original singleton
6) the subtest object tells the singleton how it turned out
#3 is necessary because Test modules tend to get the singleton once and
continue to use it, so the subtest object has to use the same object.
In Test::Builder 1.5 the state of the test no longer resides in the
Test::Builder object (this is a white lie, but becoming less so), but rather
in event handlers such as the Formatter and History objects. This means
subtests can continue to use the same Test::Builder object and the madness is
not necessary.
Instead, subtests would generate 'subtest_start' and 'subtest_end' events
which would be handled by the event handlers. There's two ways to go on this:
Plan A... each event handler that cares about subtests is actually a delegator
to the real event handler. When a subtest_start happens...
1) The delegator creates a new instance of the real event handler is created.
2) The old one is squirreled away in a stack.
3) The new handler is told how deeply it's nested.
4) The delegator starts delegating to the newly created handler.
When a subtest_end happens...
1) The delegator communicates the result of the subtest to the first handler
2) The delegator pops the stack and starts talking to the original handler
On the up side, event handlers can be written without having to worry too much
about nesting. They just need to be able to be nested. For TAP that just
means indenting the output. For XML that just means not outputting headers.
All pretty easy.
On the down side, every handler needs a delegator clogging and complicating
things. While it could be made pretty generic, it's yucky. I've known it
sucks which has stopped me from doing anything about it.
Plan B... when a subtest_start happens...
1) An event handler creates a new one of itself (the subtest handler)
2) The subtest handler is told how deeply nested it is.
3) The parent handler stores itself in the subtest handler.
4) The parent tells the event coordinator to remove itself and add the subtest
handler instead.
When a subtest_end happens...
1) The subtest handler tells its parent how things turned out
2) The subtest handler tells the event coordinator to remove itself and put
the parent handler back
3) The subtest handler forgets about the parent to avoid a circular dep
I like this because it retains the upside of Plan A, event handlers don't have
to worry too much about nesting, without each event handler having a middleman.
On the down side, the event coordinator needs a swap me out method for event
handlers. This isn't too hard, I'll just have to add a unique ID method to
event handlers.
The code to handle the creating and swapping of a subtest could be put in the
event handler superclass.
I'm going to code up Plan B, and I'd like to hear people's thoughts on solving
this problem. Rarely has my first stab at a solution been the right one in
this project.
Thanks for listening.
--
Who invented the eponym?
