# from Andy Armstrong
# on Monday 05 February 2007 11:22 am:
>To run tests locally you need to
>
>* 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.
>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?
--Eric
--
The reasonable man adapts himself to the world; the unreasonable man
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
--George Bernard Shaw
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
