----- Original Message ----
> From: Moritz Lenz <mor...@faui2k3.org>
> 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»");
> }
Regarding the disadvantages:
> However nothing in life is free, we pay for it with a
> few disadvantages:
> * We nearly double the number of built-in operators
> by adding an :ok multi
Yes, but conceptually this will be transparent to the end user, right? They'll
just know that they can add :ok to operators. They'll mentally have one extra
piece of information, not twice as many.
Are there other consequences of this?
> * We force implementors to handle operator adverbs
> and named arguments very early in their progress
> (don't know how easy or hard that is)
This might be a problem. After my (now possibly moot) rewrite of Test.pm was
finished, my plan was to write a basic Test.pm which required as few features
as needed but still allowed the spectests to run. Then you simply provide
language developers a list of features they need to implement to run the test
suite. Adding operator adverbs to the mix means a lot of rewriting of tests.
Alternatively, we can say "you don't need these at first" and Test.pm is merely
a older way of running tests. It still remains a valid alternative and new
implementers don't need to worry about adverbs.
> * 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:.
Bad:
2==2 :ok("== works");
Good:
?(2==2) :ok("== works");
I don't relish explaining, over and over again, why the first is bad and the
second is good. That being said, if this is only used for internals tests, is
this likely going to be exposed?
> So I'd like to hear your opinions: do you think
> adverb-based testing is a good idea? If you don't like
> it, do you see any other good way to tackle the
> problems I mentioned above?
So how would the following work?
can_ok
lives_ok
throws_ok
isa_ok
is_deeply
And so on? Sure, I can write extensions for this, but they're so common that
it seems a shame to not have them built-in, but what operator would they hook
to?
Also, if we're going to go whole hog on this, then may I suggest a "tests" or
"test" keyword? We might have :ok embedded in our code, in which case running
multiple sections of code might have multiple sections with :ok. How do test
numbers work? When Foo.pm calls Bar.pm calls Baz.pm and they all use :ok, we
may not know how many tests we have, so these might get handled different from
something like this:
test Unit::Customer plan 3 {
use Customer;
my Customer $cust .= new( :fname<Billy>, :lname<Bob> );
$cust.fname eq 'Billy' :ok<fname should match>;
# plan assumes 2 referrals
# won't work because we can't interpolate?
for $cust.referrals -> $ref_cust {
$ref_cust.referrer === $cust :ok<{$ref_cust.name} should have correct
referrer>;
}
}
With a scheme like this, we can separate tests explicitly written by
programmers for testing and those which are embedded. If the &referrals method
has :ok in it, this shouldn't impact the overall plan, right?
Side note: for the desugar, I'd still prefer we go with 'have/want' instead of
'got/expected'. We've been wanting to do this with TAP for a while. It reads
well and also aligns nicely for fixed-width fonts.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
