Ovid wrote:
> 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.
Right.
>> * 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.
But if the spectests are re-written in terms of adverbs, a compiler
can't use them without adverbs. If not they are not re-written, there's
no point in introducing the syntax.
>> * 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?
This will only be a FAQ for the contributors of the official Test suite,
and for people who write and test their own boolean operators. I guess
we can live with that.
All other people will assume that the operators already work.
>> 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
They would remain subs (unless somebody has a much better idea).
> 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.
I'll think a bit more about these points.
Cheers,
Moritz
