On 1 Feb 2007, at 21:37, Joshua ben Jore wrote:
[snip]
Ok, I'll give you that a user may want to ignore errors that occur
during scope cleanup but from the point of view of T::E, it seems
relatively clear that an error really has occurred.
I'd tend to think
that T::E's default behavior would be
On 1 Feb 2007, at 21:56, Nadim Khemir wrote:
On Thursday 01 February 2007 22:37, Joshua ben Jore wrote:
I'd be a happy guy if a paranoid T::E caused consternation and people
to post OMG! My stuff fails now! to perlmonks or whatever.
I use T::E extensively and I, too, would like to see a
Hi Dave,
On 2 Feb 2007, at 12:30, David Golden wrote:
[snip]
There is a different case that needs to be considered. Module Fribble
uses an eval in it's DESTROY method without error and thus Foo's fatal
error in an eval vanishes.
[snip]
Good point.
Because Perl normally warns but doesn't
On Friday 02 February 2007 10:09, Adrian Howard wrote:
[snip]
I'm unconvinced that this should be the default behaviour because I'm
fairly certain that a number of these new test failures - possibly
the majority - won't actually be indications of code that doesn't work.
For example. Module
* David Golden [EMAIL PROTECTED] [2007-02-02 13:35]:
There is a different case that needs to be considered. Module
Fribble uses an eval in it's DESTROY method without error and
thus Foo's fatal error in an eval vanishes.
I think there we can all agree at this point that global
variables are
* Nadim Khemir [EMAIL PROTECTED] [2007-02-02 16:30]:
I don't even know how we could handle the exception out of
DESTROY blocks but maybe this is already an error. I wish it
would propagate and we could handle it.
I wish! http://www.perlmonks.org/?node_id=594416
--
*AUTOLOAD=*_;sub
On 31 Jan 2007, at 16:42, Joshua ben Jore wrote:
[snip]
dies_ok { $o-annoying_corner_case } 'exception thrown';
do the SIG{__DIE__} dance make the tester write
dies_ok { $o-annoying_corner_case; 1 } 'exception thrown';
If the SIG{__DIE__} dance happens entirely in T::E (as I suggested
On 1 Feb 2007, at 16:28, Joshua ben Jore wrote:
[snip]
There's is nothing special about what T::E is doing to detect errors -
it just turns out the popular practice of looking at $@ is flawed.
That's a problem with the pattern and I expect that what it means is
that if T::E starts detecting
On 2/1/07, Adrian Howard [EMAIL PROTECTED] wrote:
On 1 Feb 2007, at 16:28, Joshua ben Jore wrote:
[snip]
There's is nothing special about what T::E is doing to detect errors -
it just turns out the popular practice of looking at $@ is flawed.
That's a problem with the pattern and I expect
On Thursday 01 February 2007 22:37, Joshua ben Jore wrote:
I'd be a happy guy if a paranoid T::E caused consternation and people
to post OMG! My stuff fails now! to perlmonks or whatever.
I use T::E extensively and I, too, would like to see a complete paranoid
module.
Someone wrote, don't
On Thursday 01 February 2007 13:37, Joshua ben Jore wrote:
I'd be a happy guy if a paranoid T::E caused consternation and people
to post OMG! My stuff fails now! to perlmonks or whatever.
Be very careful with that. I fixed a bug in Test::MockObject a while back and
a few people yelled very
On 30 Jan 2007, at 18:19, A. Pagaltzis wrote:
That could easily be accomodated by having `throws_ok` accept a
sub ref as its condition argument. Then Test::Exception could
pass the value of $@ to this sub as the first argument, and clear
$@ to force people to use that argument instead of $@
On 30 Jan 2007, at 19:48, Eric Wilhelm wrote:
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
# all Test::Exceptions subroutines are guaranteed to preserve the
state # of $@ so you can do things like this after throws_ok and
dies_ok like $@, 'what the stringified exception
Hi Nadim,
On 30 Jan 2007, at 17:17, Nadim Khemir wrote:
[snip]
The bad guys:
# Check that something died
dies_ok { $foo-method1 } 'expecting to die';
Am I the only one who got this to pass, to find out later that what
cause the
error had nothing to do with the message I displayed.
On 1/31/07, Adrian Howard [EMAIL PROTECTED] wrote:
On 30 Jan 2007, at 20:11, Joshua ben Jore wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related.
It doesn't. It's been on my
I like Test::Exception, it's a very fundamental test module with
Text::NoWarning, Test::Deep and other goodies. Still, I believe some of the
functions made available should not be there at all.
The good guys :
# Check that the stringified exception matches given regex
throws_ok {
Subject: Bad test functions in Test::Exception
From: Nadim Khemir [EMAIL PROTECTED]
Date: Tue, 30 Jan 2007 18:17:38 +0100
}I like Test::Exception, it's a very fundamental test module with
}Text::NoWarning, Test::Deep and other goodies. Still, I believe some of the
}functions made available
* Nadim Khemir [EMAIL PROTECTED] [2007-01-30 18:20]:
# Check that a test runs without an exception
lives_and { is $foo-method, 42 } 'method is 42';
Isn't this equivalent to is($foo-method, 42 , 'method is 42')?
The test framework will catch the error if any. It's just
weird to attempt to
* Pete Krawczyk [EMAIL PROTECTED] [2007-01-30 19:00]:
How about code that dies with an object? dies_ok lets you
inspect the object in $@, whereas throws_ok only lets you see
if it's part of a class. What if you want to see if $@ meets
multiple criteria? There's plenty of valid cases where
On Tuesday 30 January 2007 19:19, A. Pagaltzis wrote:
* Pete Krawczyk [EMAIL PROTECTED] [2007-01-30 19:00]:
How about code that dies with an object? dies_ok lets you
inspect the object in $@, whereas throws_ok only lets you see
if it's part of a class. What if you want to see if $@ meets
On Tuesday 30 January 2007 18:53, Pete Krawczyk wrote:
snip
No, you're not - but shunning all possible uses of dies_ok becasue you
didn't write a test as complete as you could have isn't the fault of
Test::Exception.
How about code that dies with an object? dies_ok lets you inspect the
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
# all Test::Exceptions subroutines are guaranteed to preserve the
state # of $@ so you can do things like this after throws_ok and
dies_ok like $@, 'what the stringified exception should look like';
This wouldn't be needed if dies_ok
Subject: Re: Bad test functions in Test::Exception
From: Nadim Khemir [EMAIL PROTECTED]
Date: Tue, 30 Jan 2007 20:48:55 +0100
} And finally, what if I truly don't care why something dies, just that it
} did? Why should I be penalized for writing *any* test?
}
}And how would what I suggest
On 1/30/07, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Pete Krawczyk [EMAIL PROTECTED] [2007-01-30 19:00]:
How about code that dies with an object? dies_ok lets you
inspect the object in $@, whereas throws_ok only lets you see
if it's part of a class. What if you want to see if $@ meets
On Tuesday 30 January 2007 19:09, A. Pagaltzis wrote:
* Nadim Khemir [EMAIL PROTECTED] [2007-01-30 18:20]:
# Check that a test runs without an exception
lives_and { is $foo-method, 42 } 'method is 42';
Isn't this equivalent to is($foo-method, 42 , 'method is 42')?
The test framework
On 1/30/07, Nadim Khemir [EMAIL PROTECTED] wrote:
I believe the example in Test::Exception is not as good as it could be.
# Check that something did not die
lives_ok { $foo-method2 } 'expecting to live';
Doesn't explain much about when to use it.
You'd use (lives|dies|throws)_ok when
On Tuesday 30 January 2007 12:18, Nadim Khemir wrote:
Any of the subroutines could croak. So my point is is there any point in
using lives_and at certain places when it's not used in thousands of other
places?
Sure -- when calling code that you know throws exceptions under certain
Nadim Khemir wrote:
The bad guys:
# Check that something died
dies_ok { $foo-method1 } 'expecting to die';
Am I the only one who got this to pass, to find out later that what cause the
error had nothing to do with the message I displayed. Checking that something
dies is _not_ good
On 1/30/07, Joshua ben Jore [EMAIL PROTECTED] wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related. I've just filed a bug against it at
On 1/30/07, David Golden [EMAIL PROTECTED] wrote:
On 1/30/07, Joshua ben Jore [EMAIL PROTECTED] wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related. I've just filed a bug
30 matches
Mail list logo
