we should keep this on list :) Adam Kennedy wrote: > > > Geoffrey Young wrote: > >> >> Adam Kennedy wrote: >> >>> I'd also add a small warning in that Apache::Test does seem to want to >>> dominate the entire test suite (run everything from TEST) and so may not >>> be as suitable in cases where you have 50-500 test scripts already, and >>> you just want a few to work with Apache::Test and a normal Makefile.PL >>> built with something like Module::Install. >>> >>> So I've had to limit my use of it to specific cases where mod_perl >>> dominates the purpose of the entire distribution. >>> >>> Unless you've fixed this since the tutorial :) >>> >>> Because I really don't mind the cost of having to boot up TEST 4 times >>> for 4 scripts, when only 4 out of 100 need it. >> >> >> well, there's no harm in using Apache-Test to run _everything_, even >> if only >> 4 out of 100 test scripts need the apache server - it's not like >> t/TEST adds >> any real overhead to the process, since _something_ needs to call >> runtests... > > > Well, there is a performance argument it's true, but the things that > freak me out a bit more is situations where some of the testing involves > things that might not like playing with apache.
I just don't understand this at all. $ t/TEST t/has_nothing_to_do_with_apache_at_all.t is essentially the same as $ prove t/has_nothing_to_do_with_apache_at_all.t albeit with minor semantic differences between TEST and prove. but the idea is the same - run t/test.t and pass the results to Test::Harness. what t/test.t contains is entirely up to you - interact with apache or don't. > > Imagine a distribution which has mod_perl mod_perl2 fast_cgi and so on > parts, so? A-T is perfectly designed to work with all, none, or any combination of the above. well, you can't have mp1 and mp2 in the same httpd binary, of course, but you can handle a distribution that has separate binaries with any compatible combination of the above. or WxWindows, or other various scenarios. I don't know what that is, but if it's not apache then I obviously don't care. but neither should you - there are simple ways to determine whether apache is available or not (see below) > > That it may in future situation (I can see myself encountering) lack the > necessary flexibility for my situation. A-T is nothing if not flexible. > > That the _option_ to trade off speed for flexibility isn't as easy as I > personally would like it to be, rather than that it doesn't address any > given known scenario. really, I don't know what you're saying, but it sounds vaguely like saying A-T isn't suited to some particular set of needs, when the issue may be that you just don't know how to use it appropriately. so, I just uploaded this to pause: http://www.modperlcookbook.org/~geoff/modules/WebService-CaptchasDotNet-0.06.tar.gz now, you might not be interested in the module, but here are some various platforms under which the test suite will run as a whole: - Apache-Test not installed - Apache-Test installed but no apache "found" - apache 1.0, any configuration, and set of modules - apache 2.0, "" the single test file that actually requires apache will be skipped unless - apache 1.0 + mod_cgi - apache 2.0 + mod_cgi or mod_cgid now, to trigger a "found" apache you use standard Apache-Test semantics, such as $ perl Makefile.PL -apxs /path/to/apache or $ export APACHE_TEST_APXS=/path/to/apache or a few other things. of course, now that I've released it I realize I forgot to update the INSTALL with this information. but so it goes when you rush into things... --Geoff
