That doesn't allow for what happens if both are missing.
I find the following a good general rule.
There are tests that test how the code actually works, that could
convievably be different on different platforms.
These are always on.
There are tests for issues that are almost certainly (but not provably)
going to pass everywhere, but add extra dependencies (and thus increase
risks relating to failures, perl version deps, and platform
compatibility). I include POD tests, because your pod might have issues
with older POD parsers found in some places.
They get disabled BY _by_default_ unless the end user happens to have
the module anyway, but they don't hold up the show for someone that
doesn't. And they get run in automated testing, sometimes (really
depends if the automated testing has testing the end-user case or
testing the module itself as it's primary focus)
There are tests that are ONLY going to need to be run by the author
before they can release.
They get disabled _by_default_ unless the person running the tests asks
them to be run.
Note the by defaults. In the absense of any information to the contrary,
everything but the primary functionality testing should always be off.
This keep dependencies and thus fallout to a minimum, and lets people do
what they need to.
As for naming of things, I'd consider the tests for the author to be
"release testing", and thus perhaps the name TEST_RELEASE for the
environment variable to enable for release testing? It also has the nice
property of being an imperative command when you say it. "Testing
system, test release!"
Adam K
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2006-02-03 02:45]:
But I don't know that I like disttest autodetection. I quite
like being able to run the additional tests manually if needed,
and not be limited to only during the disttest process.
Maybe do it the other way around? Define INSTALL_AUTOMATED and
INSTALL_INTERACTIVE environment variables that get set during
installation, so author tests run by default and can be skipped
when installing.
That does require touching more infrastructure, though. But it
should solve the problem long-term, because by doing it that way,
excluding tests not meant for end-user installation would not
require assinging names up front for every phase in the lifecycle
of a module and skipping each of them explicitly.
Regards,
