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