On Mon, 11 Nov 2002, Dave Whipp wrote:
> This is fine as a test, but not as documentation. Furthermore, it is
> depending on the "print" statement for its comparison (not necessarily bad;
> but I find that "golden-output" style tests tend to become difficult to
> maintain -- specific assertions tend to work better).
One thing the "golden-output" has going for it is that it gets into and
out of perl6 as quickly as possible. In other words, it relies on
perl6/parrot to do just about the minimum required of it, then passes
verification off to outside tools (e.g. perl5). I realize they can be
fragile, but at least for the moment, we can't rely on a complete
perl6 Test::Foo infrastructure, and I think that in general, we
_shouldn't_ require such a thing for the very basic tests. Because if we
do, and something basic is broken, all the tests will break because of it,
making the bug-hunter's job much more difficult.
> documentation, not code. An obvious question is how to extend it to be a
> more thorough test, whilst not spoiling the documentation. We'd want to
> intersperse text with the test-code; and probably mark a few bits as
> "hidden", from a normal documentation view (levels of hiding might be
> defined for overview vs. reference vs. guru levels of understanding).
Hm. I'm not sure how well it goes with the Perl philosophy ("the perl
language is what the perl interpreter accepts"), but we could embed the
_real_ test cases in whatever formal spec happens. This would be the
excruciatingly boring document only read by people trying to implement
perl6. I don't think real tests, which exercise specific corner cases,
mix very well with user-level documentation of any sort.
/s
