Stas Bekman wrote: > As we start adding tests running in ithreads, we no longer can use > Test.pm, which can't deal with the test counter. when several threads > print 'ok 1' we get: > > ok 136 > Test output counter mismatch [test 277] > > since in each thread, Test.pm's counter has a different value. > > Test::More has it right (via Test::Builder). So one possibility is for > mp2 test suite to switch to Test::More. The problems with that approach is: > > 1) syntax of ok and skip aren't 100% compatible between Test::More and > Test (but we can deal with that by adjusting our tests where needed). > > Prototype mismatch: sub Apache::Test::ok ($;$$) vs ($;$) at > /home/stas/apache.org/mp2-svn/Apache-Test/lib/Apache/Test.pm line 75 > Prototype mismatch: sub Apache::Test::skip ($;$$$) vs none at > /home/stas/apache.org/mp2-svn/Apache-Test/lib/Apache/Test.pm line 75
use Apache::Test qw(:withtestmore); should remedy this. > > 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. > 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. > 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. > > Another possibility is to try to hack Test.pm and possible override > things, but it's not a good idea, since it will make things too fragile > if Test.pm internals change later on. hacking Test.pm shouldn't be required. > A related issue: A-T's -withtestmore breaks the importing mechanism. > It's no longer possible to load A-T w/o importing all the symbols, i.e.: > > use Apache::Test (-withtestmore); well, that's a feature, since that action is supposed to load all the symbols that don't collide with Test::More. but why do you _not_ want to load them all? > > forces the import of all. It probably should be moved to > Apache::TestMore instead. I'll think about that a bit and see if it can work the way I want it to - I've been using -withtestmore for about a year now and it seems to meet all my needs without issue. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
