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 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
