On 5 Feb 2007, at 19:58, Eric Wilhelm wrote:
* launch the tests in // and gather their output
* display the test progress / results differently
* make it possible to attach some metadata to tests
that describes such things as which tests can safely
be run concurrently with which other tests.
Yes, except we can leave this last one off until later. Maybe never.
Here I'm guessing that a small change to the tests to make them all
"concurrent-safe" is going to be easier than trying to keep tabs on
which ones are or not and then writing that into a configuration
somewhere. Let's call it YMMV and see how often it really matters --
i.e. if you can't take the trouble to make your tests concurrent-safe,
you don't get the fun of parallelizing them.
At its simplest the metadata could be an option to EUMM to flag all
the tests as concurrency safe. It'd be nice to be able to configure
the cpan shell to enable concurrency and have it just work without
screwing up old tests that, say, trample on each other's files.
Distributing tests among multiple boxes requires all those things but
potentially there's a lot more marshalling to be done to create a
sane
test environment on each box. It's a much bigger problem I think.
Quite, but not really one that needs to be solved by the test harness.
I'm thinking the harness only needs to use the parser's exec attribute
to ssh to another box, cd, and run the test. If everything is in
place
beforehand, that should be the only difference from a locally parallel
run. I'm thinking that any amount of marshalling that gets builtin to
the harness is going to end up being wrong for somebody's
situation, so
it is better to leave it out entirely, but maybe providing a setup
hook
if exec isn't enough. Hey, couldn't the program in 'exec' even decide
whom to contact and just do it, leaving even the ssh stuff out of the
harness?
Ah - I see what you mean. Yes, that sounds eminently possible.
--
Andy Armstrong, hexten.net
