On Thursday 30 March 2006 07:32, Adam Kennedy wrote: > In contrast, as I hear chromatic express it, TDD largely involves > writing tests in advance, running the tests, then writing the code.
Not quite. It means writing just enough tests for the next testable piece of the particular feature you're implementing, running them to see that they fail, writing the code to make them pass, then refactoring both. Repeat. The important point that people often miss at first is that it's a very, very small cycle -- write a test, write a line of code. (The second important point is "refactor immediately after they pass".) > 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. For the most part, they weren't trivially easy cases that came up in my real life, so I didn't think of them. I don't feel particularly badly about that either. The code met my initial goals and only when someone savvy enough to use the code in ways I had not anticipated it found edge cases did the problems come up. I suspect you had little problem working around them until I fixed them, too -- at least in comparison to a lot of other programmers without your evil southern hemisphere nature and experience. > This I think (but cannot prove) is a TDD weakness, in that it might > encourage not critically looking at the code after it's written to find > obvious places to pound on it, because you already wrote the tests and > they work, and it's very tempting to move on, release, and then wait for > reported bugs, then add a test for that case, fix it, and release again. It seems more like a weakness of coding in general. I don't release code with known bugs, but I expect people will report bugs. Then I'll add test cases, refactor, and learn from the experience. Compare the previous version of UNIVERSAL::isa to the version I released. Not only does it have far fewer bugs, but it's at least an order of magnitude more readable. Without knowing how people will use it, it would have been much more difficult to write the code as it stands now. You see it as a failure or weakness of TDD. I see it as a success -- there's better code in the world now because of it. TDD to me is one process of soliciting and acting on feedback. Releasing code with its tests is another. It might be worth discussing the tradeoff between releasing early (with tests and the expectation that bug reports will become tests) and releasing after exhaustive "What could possibly ever go wrong here?" tests, but that's a different discussion. -- c
