On Mon, Sep 10, 2007 at 11:37:00AM -0700, Eric Wilhelm wrote:
> # from demerphq
> # on Monday 10 September 2007 10:51 am:
> 
> >> As to the core tests, they trip up like crazy, I think because they
> >> are not original in their choice of names for temporary files.
> 
> I solved that in dotReader's tests with some '. $$' action.
> 
> I was playing with the 't/' directory from perl-5.8.8 last night and 
> having very little luck.  For starters, I had to hack t/TEST to print 
> the filenames, but still came up with 995 files instead of 933, so I 
> think I did it wrong ;-)

In the core use the files as listed in MANIFEST

> I currently have no partitioning for what runs in parallel or "groups of 
> series" (ala `make -j`.)  I supposed grouping by directories could be 
> an easy switch-activated feature.  In general though, I'm thinking this 
> ventures into the realm of "test metadata", so I hesitate to ad-hoc too 
> much into it.

In the core, I found that ensuring that all the test files from the same
directory in order worked nicely. I'm sure that some tests can be run in
arbitrary order (or literally in parallel) but there are enough of them to
ensure that lots of CPUs can get fed.

The problems I had were with trying to get t/op/*.t in parallel (which should
work) and t/class/*.t (which are slow)

Also, I was trying to feed 32 cores, not 2.

I think that I documented this somewhere, but once you get to 7 tests in
parallel, where you pass the tap stream back to a central parser/reporter,
the parser in Test::Harness became the bottleneck.

Nicholas Clark

Reply via email to