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
> multiple criteria? There's plenty of valid cases where
> throws_ok just isn't enough.
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 $@ itself;
handy because $@ is maddeningly difficult to correctly preserve
for testing.
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
http://rt.cpan.org/Ticket/Display.html?id=24678. The overall moral is
when using eval{} you have to test the return value as well as [EMAIL
PROTECTED] $@
can be empty under errors which is kind of a bummer.
Anyhow, dies_ok and lives_ok are great language for talking about your
intent for testing. Just because there's a more verbose and more
powerful way to say something doesn't make it better. It's
occasionally important just to talk about things at the level of "this
dies." "this other thing doesn't." I see this as just expanding the
vocabulary.
Josh
