> Same problem, since when run under mod_perl, you must have *all* tests > loading the above. If not (and some loads Test.pm) you get the > redefining stuff, I think.
yeah, I guess you're right. hmph. > >>> 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. > >>> 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 :) > >>> 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. > 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. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
