Joseph F. Ryan wrote:
Dave Whipp wrote:Right, so whats wrong with using one of parrot's most basic ops? Thats all perl6 printThe fact that we don't need C<print> is not a good argument for not using it. Perl tests should assume that Parrot works!
is; a small wrapper around a basic parrot feature.
The problem is not that you are (or aren't) using a primitive op. The problem is that the testing methodology is based on an output-diff.
The most obvious drawback is that the use of a text-diff is that
it separates the "goodness" critera from the detection point.
Instead of saying "assert $a==5", you say
{
...
print $a, "\n";
...
}
CODE
...
5
...
OUT
If you a new to the test, there is a cognitive problem associating
the "5" with the $a. You could try using comments to match them:
{
...
print $a, ' # comparing value of $a', "\n"; # Expect 5
...
}
CODE
...
5 # comparing value of $a
...
OUT
but now you're adding extra fluff: if you change the test,
you've got more places to make mistakes. The alternative
"assert" localises the condition in both time and space.
C<assert> is also more scalable. If you are comparing 2 complex
structures (e.g. cyclic graphs), then you have to tediously
produce the golden output (you might choose to run the test,
and then cut-and-paste, but that violates the rule that you
should know the expected result before you run the test).
The alternative to the big output would be to internally check
various predicates on the data; an then print an OK/not-OK
message: but that's just an unencapsulated assert.
And talking of predicates: there are times when you want
to be fuzzy about the expected result: there may be some
freedom of implementation, where exact values are
unimportant, but some trend must be true. Consider:
$start_time = time;
$prev_time = $start_time;
for 1..10 {
sleep 1;
$new_time = time;
assert($new_time >= $prev_time);
$prev_time = $new_time;
}
assert ($new_time - $start_time <= 11);
Writing that as a golden-diff test is somewhat awkward.
There are occasionally reasons to use "print" style
testing; but it should be the exception, not the rule.
Dave.
