Kyle Hasselbacher wrote:
> On Sun, Jul 5, 2009 at 11:33 PM, Patrick R. Michaud<pmich...@pobox.com> wrote:
>> On Mon, Jul 06, 2009 at 06:28:27AM +0200, pugs-comm...@feather.perl6.nl
>> wrote:
>>> +# RT #57336
>>> +{
>>> + # XXX Right message?
>>> + my $good_message = q{Lexical 'self' not found};
>>> + my $bad_code;
>>> +
>>> + $bad_code = '$.a';
>>> + eval $bad_code;
>>> + ok $! ~~ Exception, "bad code: '$bad_code'";
>>> + is "$!", $good_message, 'good error message';
>>
>> ...I suspect that the spectests should not be checking for
>> specific error text. At least I hope that's the case, unless
>> all implementations are going to standardize error messages.
I suspect that at some point we'll get a bunch of error classes/roles,
so that you can say
ok $! ~~ XX::DivideByZero;
Or something along these lines. We just need somebody to figure out a
good structure, and spec it.
> I agree it's fragile for exactly that reason. I wrote the test as I
> did to make sure that it's an error related to the problem the code is
> showing.
+1
> For example, an earlier iteration of this test died with the
> error "Re-declaration of type X" because I was using the same name
> everywhere. I've already found a test that was supposed to die for
> one reason but actually had a syntax error.
>
> My solution in other places can be seen in r27381 and r27392. There,
> I generate the error and then check the message for things that
> (probably) ought to be in it regardless of the exact wording.
>
> eval '<1 2 3>.rt62836';
> ok "$!" ~~ /rt62836/, 'error message contains name of sub';
> ok "$!" ~~ /not \s+ found/, 'error message says "not found"';
> ok "$!" ~~ /List/, 'error message contains name of class';
This is much more sane for now.
> I didn't do that in this case since I don't understand the error
> message well enough to pick out the important parts.
When no 'self' is found, it means that we're not in a class. So the
error message "Usage of 'self' outside a class" would be better, maybe.
> I'm open to suggestion on this. If there's a great way to check that
> the error we get is the one we're supposed to get, I'll use it. If
> the consensus is that we'd rather assume the error is correct than
> have the headache of testing for precise error messages, I can write
> that way too.
I'd say until we have a good way to check errors either check for parts
like of the error message like you did earlier, or omit it entirely.
> On a semi-related topic, I find it kind of annoying that eval_dies_ok eats $!
I don't know if Rakudo needs to support contextual variables to avoid
that (which are not yet implemented), but of course you're free to to
play with Test.pm if there's an easy way to avoid that.
Anyway, thank you for your great work in the test suite!
Cheers,
Moritz
