David Golden wrote:
Adam Kennedy wrote:
But with that in mind, I still don't see much point in running them at
install-time, so lately I've modified my pod.t test so that it's skip
message is now "skipped: Author tests not required for installation"
or the like, and the tests now only run when AUTOMATED_TESTING is on.
So now the tests will still get run during CPAN Testers and the like,
but regular installation will not be impacted.
Personally, I prefer AUTHOR_TESTING and run it as part of my automated
release process.
I turn on AUTOMATED_TESTING for all the Vanilla builds to skip past
things that want user prompts -- I think of AUTOMATED_TESTING as
limiting tests to things that are safe for non-attended operation. It
would be a surprise to me to find more tests turned on for
AUTOMATED_TESTING.
Sorry to burst your bubble, but this is already happening.
There are modules using AUTOMATED_TESTING to detect automated testing
systems and adding extra dependencies, so that additional tests can be
run that would be overly onerous for someone doing an ordinary
installation to run.
I can't point to any off the top of my head, but I think at least one
thing I've written adds a dependency on SQLite under AUTOMATED_TESTING
so that it can run a whole slew of extra tests, when under ordinary
installation circumstances I wouldn't want to force someone to install
SQLite "just" for testing my module.
I'm find with adding an additional environment variable though for the
packaging state. But please lets not decide on anything right now,
AUTOMATED_TESTING is already a sub-optimal name, I'd rather make sure
that the EU::MM, M:B and M:I modules all agreed on a single consistent
name before we go and add support for it.
Adam K
