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 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.  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';

I didn't do that in this case since I don't understand the error
message well enough to pick out the important parts.

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.

On a semi-related topic, I find it kind of annoying that eval_dies_ok eats $!

> (I'm fine with us standardizing on exception types, which we
> haven't done yet, but requiring specific error messages seems
> fragile to me.)

Does this mean that there will be a better way to write this kind of
test in the future?  If that's the case, I can just stick in a TODO
note for when it shows up.

Kyle.

Reply via email to