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
