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 > 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. OK, this is one > 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 penalize, which is a rather strong umplesant word, you? You, in the first paragraph above, write that I didn't test enough (I didn't test properly, which is different), so testing with dies_ok is not enough. Fine, when the thread dies, I'll ask the author if he can change the documentation to incorporate the example you named. > I have this in the production code where I work, and it's very necessary. > If you have an interface that requires you to die on invalid input, it's a > life-saver, especially during debugging. While I won't paste code from my > work here, consider your exact case: pitty, I think most of us would benefit of good real life examples. Examples that can be put in documentation. > People have personal and organizational code standards to meet, and that's > to be expected. Be sure to update yours to the things you've mentioned. > TIMTOWTDI rules here, though, and PBP isn't a rulebook - it's a set of > guidelines that work for Damian. Other people use them to varying > degrees, and P::C even implements them, but at some point, people are on > their own. PBP? I didn't name PBP but if Test::Exception is named there and you would like to give a different opinion, I'll be very happy to listen. Cheers, Nadim.
