as easy as writing tests using threads is. Test::Builder will handle the
coordination for you. Downside: this breaks existing behavior. Rebutal: if
you're testing with fork your tests are probably broken with Test::Builder 1.5
Currently, Test::Builder has little knowledge of forking. This makes forking
in a test problematic if you expect to run tests in both forks. As people who
have done it know, it involves a lot of fiddling with Test::Builder internals
Test::SharedFork solves this, but its deeply in bed with Test::Builder and
fixing it for Test::Builder 1.5 is difficult. Test::TCP depends on
Test::SharedFork. Plack depends on Test::TCP. So it's important to make it work.
Turns out its easier to just do it inside Test::Builder 1.5. The state of the
test is encapsulated in a single object and its a not-so-SMOP to freeze and
restore that between processes. This is what geistteufel and I were working
on at the QA Hackathon.
So I propose having Test::Builder 1.5 coordinate the state of the test like it
does with threads. It'll take care of the test counter and all that for you.
There will be a switch to turn coordination off. It won't hijack fork or
* Makes writing tests with forks and doing things in parallel much easier.
* Eliminates a lot of Test::Builder hacking which often relies on
undocumented behaviors and is difficult to support.
* It breaks existing behavior.
* ...but tests which fork are probably broken with 1.5 anyway.
* It involves file locking, which introduces filesystem complications
* ...but it will only trigger when a fork runs a test.
So most tests will be unaffected.
* ...maybe it can detect if file locking is hosed and error early?
* ...file locking will be in the temp directory which is usually
a sane filesystem.
* You might want to fork and run separate tests.
* ...but this is less common than forking and wanting coordination
* ...there will be a switch to turn coordination off.
What do you think?
Who invented the eponym?