ok True, 'True is, well, True'; if True { pass('if True works'); } else { flunk('if True works'); }
You can't believe in how many ways you can screw up a compiler, and the more basic the failing test, the easier it is to diagnose; even if the look like tautologies.
That aside, this got me started:
use an alternate algorithm to extract the data, preferably one that uses more hard coded data than the algorithm being tested.
Why should your testing algorithm extract anything from anywhere? A test that re-implements parts of the tested algorithm is always a bad test. Just make up examples that don't need any extracting.
for example if you have a sub
sub s { my $str = shift; return split /:/, $str; }
in my mind the way of testing this "by extracting" is
is_deeply [s("a:b")], [split /:/, 'a:b'], $msg;
which if of course a bad idea. Testing, by definition, works with examples, so a better way to test that would be
is_deeply [s("a:b")], [qw(a, b)], $msg;
I feel a bit stupid writing this to you, since you surely know this much about testing already, but maybe it helps anyway :-)
The second thing that you can always do is to test structures, not values. For example in the case of the function about you test that the number of list items one greater than the number of colons in the source string, you could test the length of join()ed result arrays etc. Since I don't know your BUCOs I don't know how feasible that is.
In reply to Re: How does one avoid tautologies in testing?
by moritz
in thread How does one avoid tautologies in testing?
by ELISHEVA
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |