I don't know of examples off-hand but I think in a way they're correct. If you write lots of code first and then try to test it, you will look and say "it's not possible to test this so I could not possibly have written my tests beforehand - those TDD guys are fools". If you write the tests beforehand (or even if you just write your code with an eye towards how it will be tested) you end up designing your systems so that even the biggest most complex pieces are testable.
So until you actually get the testing bug, it's true that only your simplest designs are testable. Also, the problem with php (assuming you use it as a webpage generator) is that it encourages you to embed code in your HTML and so yes, it is naturally difficult to test, F On 3/28/06, Geoffrey Young <[EMAIL PROTECTED]> wrote: > hi all :) > > for those interested in both php and perl, it seems that php's native .phpt > testing feature will soon produce TAP compliant output - see greg beaver's > comments here > > http://shiflett.org/archive/218#comments > > so, TAP is slowly dominating the world... but we all knew that already :) > > what actually prompted me to write is a comment embedded there: > > "Only the simplest of designs benefits from pre-coded tests, unless you have > unlimited developer time." > > needless to say I just don't believe this. but as I try to broach the > test-driven development topic with folks I hear this lots - not just that > they don't have the time to use tdd, but that it doesn't work anyway for > most "real" applications (where their app is sufficiently "real" or "large" > or "complex" or whatever). > > since I'm preaching to the choir here, and I'd rather not get dragged into a > "yes it does, no it doesn't" match, is there literature or something I can > point to that has sufficient basis in "real" applications? I can't be the > only one dealing with this, so what do you guys do? > > --Geoff >
