perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: can't deal with ithreads, need Test::More
Date Mon, 28 Mar 2005 22:19:17 GMT
Geoffrey Young wrote:

>>>>2) Test::More relies on Test::Builder, I see that some important fixes
>>>>due to which we have to switch to T-M require Test-Builder 0.47 (Aug
>>>>2002), but looking up the changes list, it seems that many more ithreads
>>>>related bugs were fixed in the very recent versions. So it's possible
>>>>that we need at least 0.51 Nov 2004). 
>>>fwiw, 0.49 is required under persistent environments (eg server-side
>>>but I guess you're doing this *.t so you're ok.
>>No, it needs to be on the server side. I just started with external .t
>>tests to test faster.
> then you definitely need 0.49 or better if you want to use Test::More.

I'll give it a try

>>>>That means that the test suite now
>>>>will require a prerequisite which most people won't have, making the
>>>>source build out of box w/o fetching some requirements impossible.
>>>unless you mean dropping support in Apache-Test, it doesn't mean
>>>this at all.  you can require Test::More from all.t for just the
>>>thread tests.
>>The threads tests will be everywhere. We need to test *all* mp2 classes
>>under threads. the threads part will be just skipped if threads are not
> hmm, then I don't get what you're trying to do.  are you suggesting adding a
> ton of new tests?  sorry to be so thick about it :)

Let me repeat it: currently none of the mp2 classes is perl-thread safe. 
if we fix it, we need to test it. And there is a lot to test. So instead 
of rewriting tests, I'm just trying to run the same tests with and without 
threads. So potentially a huge chunk of the tests will be affected.

>>>>skipping those tests would suck, since we really need those threads
>>>>things to be tested.
>>>well, we can test them ourselves as best we can, but skipping tests on
>>>platforms isn't all that bad.  a large percentage of people skip them
>>>routinely anyway, or don't care when they fail.  or at least I suspect
>>>as much.
>>I'd rather follow Adam's suggestion and bundle Test::More and have
>>everybody run tests. This is because *we* test only very limited number
>>of platforms and very few configurations.
> bundling seems to just add lots of work on our end - the continuous syncing
> on our end, for one.  but I guess I'm ok with it if you want to go ahead.
> might as well use 0.54 or whatever is the latest cpan release.

Certainly, I'll use the latest. At least we can give it a try. I may 
eventually give up on this fun task, so there will be no changes at all.
Ideally I'd like to make a new branch and work there. But I don't want to 
do the merge with renamed branch twice, that's why it'd be really helpful 
if you had it merged asap.

>>Right, it does work for you. But do you agree that it partially breaks
>>the import mechanism?
> yeah it was never ideal :)
>>In any case having Apache::TestMore as a subclass of Apache::Test seems
>>like a cleaner interface to me and simplifies the logic inside A-T::import.
> I don't know about simplify - a subclass will either need to reimplement
> Apache::Test::plan() to get the extra foo or figure out some way that a call
> to SUPER::plan() will do the right thing.  in either case, it's work.  but
> I'll try and take it on "soonish."  in fact, there's quite a bit of
> refactoring I'd like to do - implementing the PHP stuff showed me just how
> much private variable stuff is going on that should really be shared across
> the various TestRun* and TestConfig* classes.

But it has to be done. If we switch exclusively to Test::More it's going 
to be error prone to leave it to the import flag to figure out, not 
talking about the ugliness of typing it all over.

One approach you could use though is ignore the special import argument 
and use Test::More if Test::More is in %INC already. So if we load it from 
t/TEST and startup, 'use Apache::Test' will automatically use T-M 
everywhere. That works for me.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message