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 tests), 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 Test.pm 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 available.
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.
And 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 user 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 http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
