Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)

Dave Whipp wrote:

>"Sean O'Rourke" <[email protected]> wrote in message > 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.
>>    
>>
>
>I see where you are coming from ... but is the IO infrastructure really the
>most primitive thing to rely on? It may be at the moment; but I expect
>that it will become more complex. C<print> may be a built-in right now;
>but it should probably move to a module later.
>

A module?  For something as basic as print?
I hope not, that would certainly be a pain.

>If we can't rely on C<assert(0)> to kill a test (and C<assert(1) not to>;
>then things are pretty badly broken (assuming that C<assert> exists).
>

I think the point that Sean was trying to make was that for some kind test
infrastructre to be available to Perl 6 to test Perl 6 with, it would have
to be implemented in Perl6 first.  The problems with this are:

1.) Perl 6 at the moment is *extremely* slow.  This has much to do with
    the huge grammar PRD has to handle, but why make the testing any slower
    than it already is?

2.) If there is a problem with some part of the compiler that the testing
    mechanism was built with, it will break the testing mechanism.  This 
will
    needlessly break all of the tests, and could be very painful to debug.

>If we are going to pick a very small subset on which almost all tests
>will depend ... isn't it better to pick the test-infrastructure itself to be
>that dependency; rather that some arbitrary module (like IO).
>
>
>Dave.
>
Well, the P6C print implementation is as basic as it gets; all it
does is take a list of arguments, loop through them, and
call parrot's print op on them.  Although the full implementation will
be more complex (as it will have to handle printing to filehandles other
than stdout), the testing implementation won't have to deal with that.
However, assert is bound to be more complex, since it will have to handle
and compare many different types of data structures.