----- Original Message ----

> From: Moritz Lenz <mor...@faui2k3.org>

> >   test Unit::Customer plan 3 {
> >       use Customer;
> >       my Customer $cust .= new( :fname, :lname);
> >       $cust.fname eq 'Billy' :ok;
> > 
> >       # 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>;
> >       }
> >   }
> I'll think a bit more about these points.

I've been thinking about this and have realized that it also solves an 
intractable problem with Perl 5 tests:  identifying tests.

By promoting 'test' to a first class concept (not just adjectives), you can 
"name" a test.  Right now, I'm trying to write App::Prove::History 
(http://github.com/Ovid/app--prove--history/tree/master), a bad name for code 
which saves the state of test runs.

One incredibly thorny problem I have is that tests are identified by the name 
of the file.  Reorganize your tests in directories or rename 'em?  You've just 
lost your test history.  However, if tests have an implicit name, developers 
are no longer locked into a directory hierarchy to identify their tests.  This 
also brings us conceptually closer to the xUnit crowd.

I would say for the above, if &referrals had embedded :ok tests, they could be 
output as warnings (if failing) or be provided via some mechanism that would 
let them be embedded into a TAP stream (or other test protocol) so that the 
information is not lost.

I also wonder if 'plan' might not belong there.  Not all testing protocols 
implement that and perhaps some developers won't want it.  So long as their 
tests don't prematurely exit, they know they've run all of their tests.

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

Reply via email to