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 { $foo->method3 } qr/division by zero/, 'zero caught okay';
# Check an exception of the given class (or subclass) is thrown
throws_ok { $foo->method4 } 'Error::Simple', 'simple error thrown';
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 enough. One should check more thorowly. Yes, I know I can
use throws_ok but why have dies_ok ? I'd say that dies_ok might make your
testing worse. Use only the superior throws_ok.
# Check that something did not die
lives_ok { $foo->method2 } 'expecting to live';
Is the above realy a test? Ok but testing what? why wouldn't we wrap all our
test in lives_ok? No, I don't think lives_ok makes any sense. I'd be very
happy to see real examples of lives_ok that add anything to a test suite.
# 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 catch
something when the expected result is to pass.
# 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 didn't exist.
I postulate that Test::Exception would be even better if we removed the bad
guys.
Cheers, Nadim.