Geoffrey Young wrote:

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.

I was already using:

  use Apache::Test '-withtestmore'

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.

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.


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.


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.


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?

I don't know. Why taking this an option away in case someone will need it later?


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.

Right, it does work for you. But do you agree that it partially breaks the import mechanism?


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.

--
__________________________________________________________________
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]



Reply via email to