Just a quick note,
Still waiting on my fan, it's getting shipped in from Amurricah.
I wrote a run_tests_sub.py the other day that uses subprocess to run
each xxxx_test.py in the trunk/test directory.
It will run with an optional threads paramater: -t num_threads
$ run_tests_sub.py -t 4
Apparently this runs faster on mult-core.
It should output results similar to run_tests.py though may need
tweaking to get it run transparently in place of run_tests.py for the
build page.
Speaking of the build page, Rene and I have had a few ideas for a
combined build / test web app that collected builds and test statistics
( profiling / passes etc). Also, a means to distribute the writing of
tests. Many hands make light work.
If it was possible to be assigned a stub of a test to fill out and then
post it back painlessly we could quite quickly increase the coverage of
our tests. If twenty people filled out 1 test a week, then over a month
that would be 80 extra unit tests.
ATM there are "FAILED (failures=232)", unimplemented tests and possibly
that many again that haven't been stubbed out waiting to be written.
$ run_tests.py -i
Will show tests that need fleshing out.