On 2011.10.28 6:52 AM, David Golden wrote: > Without looking at the actual code, I would guess that the complexity > is implementing subtests while preserving the legacy procedural > interface that wraps calls to a global singleton.
No, that's not really the problem. It was when Ovid originally implemented subtests. In 1.5 the singleton will not contain test state, that will be in event handlers held by the EventCoordinator. So the Test::Builder singleton does not have to change like it currently does. The problem is all the event handlers need nested state. Formatters have to know how to be nested (ex. indentation for TAP or not writing the header/footer for XML). History is no longer a linear set of events and results but a tree. User written event handlers (Test::NoWarnings is one example) also have to cope without pushing complexity onto the test module authors. And if subtest state is implemented as a new object (which it's looking to be) then the result of the subtest has to be communicated back to the parent and assimilated. I finally have solutions for these which don't suck, but I like to solve complex problems by eliminating the problem if possible. So the question is if we need *subtests* meaning a block of tests which is an entirely separate state or if we just need named blocks with a separate plan? This question is orthogonal to the complexity of implementation and it only applies to what Test::Builder produces, not what TAP::Harness reads. With the 1.5 architecture changes in test state are now granular events, rather than it happening all over the place. Subtests are looking easier than I thought. -- Whip me, beat me, make my code compatible with VMS!
