On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz <[email protected]> wrote:
> So Larry and Patrick developed the idea of creating an
> adverb on the test operator instead:
>
> $x == 1e5 :ok('the :ok makes this is a test');
>
> This is an adverb on the infix:<==> operator, and might
> desugar to something like this:
>
> multi sub infix:<==>($left, $right, :$ok) {
> $*TEST_BACKEND.proclaim($left == $right, $ok)
> or $*TEST_BACKEND.diag(
> "Got: «$left.perl()»; Expected: «$right.perl»");
> }
>
> (Daniel Ruoso also proposed to call the adverb :test
> instead of :ok, making it easier to read but a bit
> longer; my happiness doesn't depend on the exact name,
> but of course we can discuss it once we have settled
> on this scheme, if we do so).
I like this idea and with it built into the language itself, there will be
much less of an excuse to skip testing. I like the adverb form, which seems
more perl6 than C. Naming it something like :test is a better idea than :ok
as that seems a bit more direct.
There isn't much in the spec concerning namespaces, other than the default *
namespace. Is there any reason why the testing framework can't go in it's
own namespace?
> * We nearly double the number of built-in operators
> by adding an :ok multi
> * We force implementors to handle operator adverbs
> and named arguments very early in their progress
> (don't know how easy or hard that is)
> * Testing of operators becomes somewhat clumsy. If you
> * want to test infix:<==>, you won't write
> '2 == 2 :ok("== works")', because you test a
> different multi there. Instead you'd have to write
> something like '?(2 == 2) :ok("== works")', where
> :ok is an adverb on prefix:<?>.
>
These are mostly disadvantages to implementors, not users of the testing
framework. I'd rather the implementations struggle to implement a built-in
testing functionality than users of the language struggle to use the
built-in testing.
> I'll send another mail on the subject of pluggable
> testing backends in order to allow different emitters
> (TAP output, storage into databases, whatever)
This is a requirement for me. Having only TAP emitters may not integrate
well. It would be nice if the spec, if added, would allow flexibility in
this realm. I would actually like to see a flexible system that allowed me
to define a new emitter, say for the cases where you want to integrate perl6
testing into an existing testing framework (think automated builds and
tests).
-Jason "s1n" Switzer
