Moin,
On Thursday 30 March 2006 17:32, Adam Kennedy wrote:
[snip]
> Calling ->method( \"" ) or ->method( \undef ) or ->method ( sub { die
> "foo" } ) and a dozen other things like that is intentionally provoking
> that code into blowing up.This are good things, but checking every param on every call to be well-formed is quite expensive. So I can imagine why people don't do this :) > In particular, it forces you to examine your param-checking and similar > things. > > If your methods takes a reference to a string, can it handle a > reference to a constant string. Fun ensues when you simple use -Mbigint, ref(1) suddenly becomes true... Most code blow up on this because checking for ref($a) instead of ref($a) eq 'HASH' etc. > I don't know what you'd call this sort of thing, maybe Evil Testing? Hehe. > It helps you to answer the question "what can possibly go wrong" and > weeds out tons and tons of bugs in advance. > > In contrast, as I hear chromatic express it, TDD largely involves > writing tests in advance, running the tests, then writing the code. > > But often it's not until you write the code that you have some idea of > the sorts of things that might break it, and so you have a good idea of > the sorts of evil you need to concentrate on. > > In my use of Test::MockObject and UNIVERSAL::isa/can I found I was > initially able to cause them to fail quite easily with fairly (to me) > trivially evil cases that would occur in real life. Unfortunately, to do such evil testing, the tester needs to be a different person than the developer. Really. You never are able to break your code like $JoeRandomPerlDeveloper. But in most projects the Testing Manager is also the Lead Programmer, Documentation Supervisor, Most Prominent User and Quality Assurance Senior Manager in one person. [snip] > I've submitted repeated reports of bugs that seem to occur all in a > similar location near this API boundary area, and after the first one I > would have though it was a clue to throw every possible bad type of > thing you can think of at those points, before releasing again. OTOH, you cannot catch every evil and malformed input, at least not with practical costs in memory/time trade-off (especially developer time!), so some cases are on the order of "dont do that". I think the only thing we can all agree on is that "the more tests the better" :D best wishes, Tels -- Signed on Thu Mar 30 18:08:15 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Let's say there are a thousand. But there are 284 million people in this country. You can't have public policy that is aimed at 100,000 people when the other multi-multi-millions are also involved. You can't do it that way." - Jack Valenty in http://tinyurl.com/2y65n
pgpnRKVfpUvwd.pgp
Description: PGP signature
