# from Nicholas Clark
# on Monday 05 February 2007 03:24 am:
>Important differences were
>
>1: you only print out the entire test results as an atomic line when
> it has finished
>2: You have no idea which test is going to finish next
>3: You can't print running progress on tests
Ah, there's the rub. I was planning to simply fork before hitting
_runtest(), then serialize the parser object[*] from the slave to
collect it in the aggregator in the master. I guess I figured that
legible progress reporting could go hang :-D
[*] Though Storable::freeze($parser) fails because of globs. But,
YAML::Syck is perfectly happy to dump it. We shouldn't need the
_stream attribute after the parser is done, so maybe we can delete that
with $parser->freeze?
So, I'm thinking progress reporting comes from the harness subprocess on
STDOUT (in "$i/$n\n" form), and TAP just gets read by the parser as
usual (though one level deeper in subprocesses), then a stripped-down
parser object gets shipped back to the master for aggregation. With
all of that in place, I think we could figure out what to do about
outputting running progress from the master (starting with simply which
tests are complete.)
Summarizing, I think it would be very feasible as a subclass given these
refactorings and additions:
o TAPx::Harness::test_loop() method as overridable inner part of
aggregate_tests(), with some rejuggling of $periods calculation
o TAPx::Harness::_do_test(\%args) method as overridable inner part
of _runtest(), allowing the subclass to not have to deal with args
processing, spool, etc.
o TAPx::Parser::freeze() -- disconnect _stream and etc., serialize
o TAPx::Parser::thaw() -- deserialize (no need to reconnect)
Sound workable?
Thanks,
Eric
--
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
--Alan Kay
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
