# from Adrian Howard
# on Monday 31 December 2007 11:18:
>That's been my experience too. I've caught many nice bugs that would
>have been missed by completely-clean slate tests.
Are they bugs in the tests or actual bugs?
>1) Windows & fork :-/
Big deal? Are the issues relevant to preloading or only concurrency?
If the latter, then just turn off the concurrency feature.
>2) With previous test parallelisation hacks that I've put together
>the biggest problem I come across is test suites that assume that
>only one test script is running at a time. My hunch, from having had
>to mess with several large messy commercial test suites in the past,
>is that something like T::A is more likely to work than a forking/
>parallel solution for many suites.
Again, preloading or concurrency? Concurrency. If preloading-only via
fork gives a working test suite and loads faster than aggregation, it
is a win independent of whether your tests play nice with concurrency.
>Not that a nice parallelisation system wouldn't be welcome too -
>especially one that can distribute tests over multiple machines.....
Bit of a different bag of beasts there. Though I suspect it is doable
in much the same code as a forking preloader (e.g. reading results on a
pipe and etc.) For instance, assume a master and slave preloaders
where the master does the SGI::FAM bits and restarts the slaves
whenever the files have changed (or something like that.) Which test
to run maps from per-process to per-node quite nicely and independently
of the startup code.
--Eric
--
Moving pianos is dangerous.
Moving pianos are dangerous.
Buffalo buffalo buffalo buffalo buffalo buffalo buffalo.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
