Testing failures not necessarily actual failures for a given installation

["Kinyon, Rob" <Ro...@progressive-medical.com>]

It's been indicated to me that many of the tests which may or may not
fail may not indicate that MP is unusable for a given installation. Are
there any docs to explain what feature a given test tests? Or, is there
a way of indicating to "make test" which features you actually care
about?

Thanks,
Rob Kinyon

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Testing failures not necessarily actual failures for a given installation

[Stas Bekman <st...@stason.org>]

Kinyon, Rob wrote:
> It's been indicated to me that many of the tests which may or may not
> fail may not indicate that MP is unusable for a given installation. Are
> there any docs to explain what feature a given test tests? Or, is there
> a way of indicating to "make test" which features you actually care
> about?

There is no such dedicated documentation, but you can ask. The top level 
directory of the test indicates the functionality that it's being tested. So 
looking at the list of the reported by you failures:

t/apr-ext/uuid.t             255 65280     3    3 100.00%  1-3
t/filter/both_str_con_add.t                4    3  75.00%  2-4
t/protocol/echo.t             22  5632     3    2  66.67%  2-3
t/protocol/echo_filter.t      22  5632     3    2  66.67%  2-3

t/apr-ext is for using perl glue APR:: API outside mod_perl, which is far from 
being usable at the moment and you don't need it for mod_perl.

t/protocol is for testing the non-HTTP protocol functionality. If you don't 
write/use protocol modules you shouldn't care about it. You always have the 
HTTP protocol.

some tests try to test a feature which relies on another feature, so in case 
of t/filter, which is a group of tests to test filters, the test
t/filter/both_str_con_add.t was relying on the protocol module, but it by no 
means indicates that you can't use filters, since we know that it's the 
protocol module (sockets) that you have the problem with.

Therefore if you don't use protocols and don't use external APR api, you are 
just fine. Nevertheless it'd be great to resolve the other failing tests if 
you can help.

BTW, you also need to run 'make test' inside the ModPerl-Registry directory to 
complete the test suite. It's normally run automatically when the first 'make 
test' succeeds. We are considering to run it regardless the success of the 
first one.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html