On 31 Dec 2007, at 11:15, Ovid wrote:

--- Eric Wilhelm <[EMAIL PROTECTED]> wrote:

Now, assuming that both ways carry the same caveats, I too would
prefer
the latter because it not only eliminates load time, but also allows
concurrency and provides isolation via the boundary between child
processes.

I may be a bit of a heretic, but after years of using Test::Class, I
rather like the fact that I don't have the isolation between tests
because a lot of code makes incorrect assumptions about all sorts of
things.  For example, here's a couple of time bombs waiting to happen:
[snip]

That's been my experience too. I've caught many nice bugs that would have been missed by completely-clean slate tests.

Of course there have also been many nice bugs caught by clean-slate tests that would have been missed in a persistent environment ;-)

I don't think it's a particularly clear cut issue.

On the fork front two issues come to mind.

1) Windows & fork :-/

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.

Not that a nice parallelisation system wouldn't be welcome too - especially one that can distribute tests over multiple machines..... if I only had some spare tuits :-)

Cheers,

Adrian

Reply via email to