----- 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>;
> > }
> > }
<snip>
> 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.
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
