----- Original Message ----

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

>     * the word 'is' is overloaded in Perl 6
>    * if we export subs is() and ok(), we clutter the
>      namespace with subs with short names 
>    * is() is rather imprecise; it doesn't say *how*
>      things are compared.
> 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 may all be irrelevant, but I'm tossing it out here in case anyone thinks 
of how it might impact things.

I'm not entire certain how I feel about this yet, but I love the core concept 
of making testing a first class feature (well, duh ... of course I would say 
that :)

I'd like for this to be thought through really carefully lest we create an 
interesting idea which is hampered by its implementation.  Specifically, I'm 
concerned about diagnostics.  What we'd ultimately love to have in TAP is some 
way of improving diagnostics (pseudo-TAP).

  is 3,3 'constants are constants;
  # ok 1 - constants are constants
  # have: 3
  # want: 3

Now we have a curious situation:

  multisub foo(Str $bar);
  multisub foo(Int $bar);

If we're testing what we should pass to &foo:

  is 3,"3" 'constants are constants;
  # ok 1 - constants are constants
  # have: 3
  # want: "3"

Integration tests will still do OK, but unit tests may have issues and this 
could be an expectation violation.  What does it mean that the string 3 eq the 
integer 3?


  my $bar = 284;
  ok $bar, '$bar should be true';
  # ok 1 - $bar should be true
  # have: 284
  # want: True

That can also look a bit strange, particularly if someone is coming from a 
different language background.

How would this new system handle diagnostic information?  One thing which might 
mitigate this is something we've wanted in newer versions of TAP:

  my $bar = 284;
  ok $bar, '$bar should be true';
  # ok 1 - $bar should be true
  # test: ok $bar, '$bar should be true';
  # have: 284
  # want: True

By letting programmers see the exact line of code for the test, the type 
information *might* not be as important.  I'm unsure.

One possibility is to look at the &Test::More::cmp_ok function:

  $ perl -MTest::Most=no_plan -e 'cmp_ok 3, "==","2"'
  not ok 1
  #   Failed test at -e line 1.
  #          got: 3
  #     expected: 2

If you change "2" to "3", the test still passes, but we could force it to not 
pass unless eq is passed in as the second argument.  Then we could have the 
following diagnostics:
  perl6 $ perl -MTest::Most=no_plan -e 'cmp_ok 3, "eq","3"'
  not ok 1
  # have: 3
  # test: eq
  # want: "3"

And then it's crystal clear why it failed.


Reply via email to