# from David Golden
# on Monday 30 July 2007 05:34 am:
>The issue at hand is really *release* testing (i.e. did I bump the
>version, did I test my Pod, do I use good style, etc.) being mixed
>with *functional* testing -- and the corresponding push for release
>testing modules being included as requirements.
Yes. We want to know that the author tested the code and went through
the checklist before the release. We would like to be able to verify
it ourselves, but we don't want all of that to get in the way of
installation.
>For that, I blame -- among other things -- Module::Starter for
>including pod.t and pod-coverage.t and with a default setting to run
>tests. Better would have been to skip tests unless
>$ENV{AUTHOR_TESTING} or some similar flag was set.
Again, yes. Though I'm going to stick with "delete them."
I think the important bit is that `make test` only runs tests which
verify the module's functionality.
Anything else needs to be a separate test target or out-of-band tool.
The fact that this is ugly, opaque, and error-prone should tell us
something:
AUTHOR_TESTING=1 \
TEST_THE_NETWORK=1 \
TEST_THE_HARDWARE=1 \
ADD_THOSE_OTHER_TESTS=1 \
TEST_EVERYTHING_REALLY_I_MEAN_IT=1 \
make test
Compare to something as simple as:
prove t_author t_network t_hardware t_other t_more t
Or
./Build testall
--Eric
--
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
--Alan Kay
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
