[cgiapp] RFC: CGI-Application-Plugin-DetectAjax

MidLifeXis at PerlMonks midlifexis at wightmanfam.org
Tue Oct 19 11:14:40 EDT 2010



On 10/19/2010 08:36 AM, Jiří Pavlovský is presumed to have written:
>   On 19.10.2010 15:30, Mike Tonks wrote:
> > I did get an install error out of the box due to a missing dependency:
> > Test::MockObject
> 
> I'll fix that.

I have seen many modules that require an end user (not a developer of a module, 
but a user of it) to have all sorts of testing infrastructure built up, even 
though they do not do any type of development work, at least not at the module 
level.  They end up needing to install modules that are only used at the build / 

install phase of the modules they would like to use.  I don't think that much of 

this is necessary.

Alias wrote an article, http://use.perl.org/~Alias/journal/36128, discussing a 
trend / agreement / protocol to use RELEASE_TESTING and AUTOMATED_TESTING 
environment variables to trigger different tests based on the different 
environment in which you are running.

You have three audiences (very broad slices here):

1) Those that assume that the logic is correct and just want to test to  see 
that their build has progressed properly.  These users probably don't need or 
want many of the Test:: modules.  These users  should be able to assume (normal 
caveats apply) that they should not  need to exercise the logic of the entire 
module, if the POD checks out, style choices are made, and so on, but just that 
it loads,  external dependencies have been met, etc.  Unless a module is 
required to meet these goals, it should not, in my opinion, be a requirement for 

installation (including the default set of tests).

2) Those that want to run the full test suite (developers, for example),  who 
should run RELEASE_TESTING prior to pushing changes to you.  These  are changes 
that would possibly effect the logic of the system and  should exercise a larger 

portion of the test suite, including POD formatting, coverage testing, perltidy, 

PBB checkers, etc.

3) Those that have a testing environment set up.  This could be an  environment 
like (1) or (2), so I could float either way on this one,  but would probably 
lean towards making it act like (1) unless  RELEASE_TESTING is also set up.

Could I request that running the tests requiring testing-only modules are only 
run if RELEASE_TESTING is set (and fail if the module is not available)?  If 
RELEASE_TESTING is not set, then the tests should be skipped and a require never 

done for T::MO.

Thoughts?

Verbosely yours,
MidLifeXis


More information about the cgiapp mailing list