I've been thinking about automated testing again. I know this is a
bad habit and I should stop it and just get on with my work, but here's
where I'm at:
Sometimes it's beneficial for an automated tester to install
additional packages (in software I'm releasing, Test::CPANpm and
Tyler MacDonald wrote:
How does everybody feel about making this a defined feature in
the META.yml spec? Something like:
optional_features:
- automated_testing:
description: Automated testing of all of this package's features
requires:
DBD::SQLite2: 0
If
While a META.yml file provides a good description of what is required,
the dependencies WILL change once the Metafile.PL runs.
Actually, that should read will often change, 90% of the time not
turning on the dynamic_config flag in the process.
So while we are on the subject of META.yml, I
Adam Kennedy [EMAIL PROTECTED] wrote:
So while we are on the subject of META.yml, I think the dynamic_config
approach is horrible, because it defaults to an efficient error case and
relies on the author to fix the error, rather than defaulting to the
inefficient correct case, and giving the
Adam Kennedy wrote:
To give you some more data points, imagine the automated testing
additions applied only on Win32. How would you then specify the deps?
#187 on the TODO list for M::B is to implement the dEx[1] (Dependency
EXpression) language for inserting complicated requirements in
Randy W. Sims wrote:
Adam Kennedy wrote:
To give you some more data points, imagine the automated testing
additions applied only on Win32. How would you then specify the deps?
#187 on the TODO list for M::B is to implement the dEx[1] (Dependency
EXpression) language for inserting complicated
