Re: Flunking tests and failing code
On 12/6/05, chromatic [EMAIL PROTECTED] wrote:
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote:
I wonder if there is a macroey thing that we can do here. That is,
could we make:
ok(1);
is(1, 1);
like(foo, /foo/);
Into:
ok(1);
ok(1 == 1);
ok(foo ~~ /foo/);
Can you do it without giving up the nice diagnostics that
Test::More::is() provides?
The answer to your question was in the next sentence:
And lexically analyze the argument to ok() to find
out how to report the error?
I guess that wasn't much of an answer, but more of a question.
Anyway, yes, that is what I was hoping. However, I agree with Brent
Dax about keeping the test module simple--at least for the compiler
test suite. However, I think this DWIMmery might work well in module
test suites.
That still leaves the problem of what to do with fail() and is() in
the compiler suite.
Here's a handwavey crack at what I was talking about:
my $comparators = set == ~~ eq
macro is($arg, ?$reason_tree) {
my $reason = $reason_tree.run;
Re: Flunking tests and failing code
On 12/6/05, Luke Palmer [EMAIL PROTECTED] wrote:
That still leaves the problem of what to do with fail() and is() in
the compiler suite.
Here's a handwavey crack at what I was talking about:
Ack. Accidentally sent the half written message. Let's try again:
my $comparators = set == eq === ~~ lt ...
macro is($arg, ?$reason_tree) {
if $arg ~~ :(App (func = my $f, args = my @args))
$f (in) $comparators {
internal_ok($arg, '@args[0] $f @args[1] failed: ' ~ $reason_tree)
}
else {
internal_ok($arg, $reason_tree)
}
}
Except hopefully with quasiquoting instead of simple interpolation.
Luke
Re: Flunking tests and failing code
On Mon, Dec 05, 2005 at 07:54:25AM +, Luke Palmer wrote: I wonder if there is a macroey thing that we can do here. That is, could we make: ok(1); is(1, 1); like(foo, /foo/); Into: ok(1); ok(1 == 1); ok(foo ~~ /foo/); And lexically analyze the argument to ok() to find out how to report the error? Something in the style of Smart::Comments which looks at subexpressions and tells you about them automatically. I like that a lot. -kolibrie
Re: Flunking tests and failing code
Nathan Gray: Luke Palmer: I wonder if there is a macroey thing that we can do here. That is, could we make: ok(1); is(1, 1); like(foo, /foo/); Into: ok(1); ok(1 == 1); ok(foo ~~ /foo/); And lexically analyze the argument to ok() to find out how to report the error? Something in the style of Smart::Comments which looks at subexpressions and tells you about them automatically. I like that a lot. ok(that ~ /I/) -- Grtz, Ruud
Re: Flunking tests and failing code
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote: I wonder if there is a macroey thing that we can do here. That is, could we make: ok(1); is(1, 1); like(foo, /foo/); Into: ok(1); ok(1 == 1); ok(foo ~~ /foo/); Can you do it without giving up the nice diagnostics that Test::More::is() provides? Note that Test.pm in Perl 5 uses ok() for everything and that DWIMmery too often doesn't. -- c
Flunking tests and failing code
There's a bikeshedding question of some visibility: now that we have a Cfail builtin, what do we do with CTest::fail? There's plenty of code out there that uses fail as an exported function from pugs' Test.pm or Perl 5 testing modules. We want to keep Test primitives exported and fun to use, to encourage people to use them a lot; so requiring a fully qualified call would go against the grain. But the builtin has even more of that concern: it should become the more common, too. If one is to be renamed, it looks like is the Test one, despite existing legacy code. Discussion on #perl6 brought up flunk as a candidate name. Its merits, including its, uh, dropout cuteness, are many; it rings well against fail, alludes to tests, can probably be backported to the Perl 5 test modules, etc. What say? [++] dduncan autrijus -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Flunking tests and failing code
On 12/5/05, Gaal Yahas [EMAIL PROTECTED] wrote:
There's a bikeshedding question of some visibility: now that we have a
Cfail builtin, what do we do with CTest::fail?
Is it possible to do nothing with it? That is, can we coerce the Test
module to understand when the main program fails? This may be
problematic, as it is occasionally desirable to call fail from
within a function while you are testing.
There's another problem that I've been thinking about with regard to
Test. We have the prefix:is builtin, used like so:
class Foo {
is Bar;
}
Which can be interpreted as a regular compile-time function (I guess
we call those macros) that acts on some topic container (think io[1]).
So we seem to have stolen that from Test, too.
I wonder if there is a macroey thing that we can do here. That is,
could we make:
ok(1);
is(1, 1);
like(foo, /foo/);
Into:
ok(1);
ok(1 == 1);
ok(foo ~~ /foo/);
And lexically analyze the argument to ok() to find out how to report
the error? Something in the style of Smart::Comments which looks at
subexpressions and tells you about them automatically.
The only downside is that you can't refer to ok as a coderef. I
think that is a small price to pay for such a wonderful DWIMmity.
Luke
[1] http://www.iolanguage.com
