On 2012-06-03 18:14, Phil Pennock wrote:
I'm thinking that a hash used as a set, where the keys are "features",
could be used in the existing munge, and hash is emptied at the start of
each test, and reading the test driver could add some more keywords
(where we currently have "need_ipv4" or whatever, for instance) which
will toggle on the hash entry.
So the test case for DNSSEC would include "tests dnssec" as an entry
near the start, and munge would have:
unless exists $test_features{'dnssec'};
after the substitution to be suppressed.
Using /^tests\s+(\S+)\s*$/ for the test reading, we can then just take
$1, shove it in as the key into $test_features and so the work to add a
new test is "invent a string, use it as 'tests foo' in the driver
script, check for $test_features{'foo'} on the bit of the rig we want to
adjust". That's the minimum of fuss for each new change.
I can see how it works, assuming that the substitutions can be
made versatile enough to do whatever's needed. This particular case
requires the removal of an entire line; is that possible without
forcing perl to slurp the entire file rather than working line-by-line?
However, I'm concerned slightly that it's a negative test. While
less work, it is more risky in that the new munge added to avoid
byproducts of $new-feature (in cases not specifically testing $new-feature)
get applied everywhere and could mistakenly mask some other problem.
I'd be happier with a positive test and having to deliberately apply
the munge only where it is identified as being needed, even though
that's more work.
--
Cheers,
Jeremy
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
