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.