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.

Reply via email to