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

"Joseph F. Ryan" <[email protected]> wrote in message
news:[email protected]...
> A module?  For something as basic as print?
> I hope not, that would certainly be a pain.

My understanding is that C<print> will be a method on C<IO::stream> (or
whatever), which has a default invocant of $stdout. This module might be
included automatically, so users don't need to know about it.

Anyway, calling C<print> "basic" is a very biased point of view. Its the
viewpoint of someone who knows how things are implemented.

> >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.

I think it would be a mistake to assume that we can't use a testing
infrastructure for tests. Sure, there need to be some implementation-centric
unit tests that depend on almost nothing: but those tests should be run as a
guard around a main regression (i.e. a regression script should say "do
clean checkout; run sanity checks; if OK, then run regression"). If
C<perl6 -e 'assert 1'> fails, then things are broken.

It is also a mistake to base the decision on the fact that perl is currently
too slow. This will be fixed: performance of dispatch will be crucial all
perl scripts, not just tests.

> >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).
>
> 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.

This feels like a false augment (even if the conclusions are true).

Contrast: C<assert> takes a single arg, and evaluates it in boolean context.
It if the result is false, then execution terminates.

OTOH, C<print> takes a list of args; iterates through them, and calls a
polymorphic (in parrot) method on each.

If I make a primitive assert op in parrot, then the perl implementation is
rather basic.

assert_equal is a bit more complex. But the complexity can be structured. We
don't need, initially, to implement heterogeneous comparisons, for example.
At a more detailed level: a test that compares integers doesn't need strcmp
to work.

You seem to be concerned about a boot-strapping problem. I want to make the
assumption that there is a level of functionality below which it is
pointless to run user-level tests.


Dave.