Hmmm... Went to a test driven development this evening. Quite a hostile audience, and a good presentation, but as predicted very academic:
- Shooting fish in a barrel - if I fire 20 tests at this barrel and don't hit a fish then there are no fish in the barrel? But much more likely to prove that the code does what the programmer thinks it does.
- You only test for the errors that you anticipate. These are the same as the ones you program for. Fair enough, agile says you add tests for those you don't anticipate, but those have already become bugs so TDD's "test before code" principle has failed.
- Doubles code size. Complexity is super-linear in code size. Big minus for agile workflows.
- Brain stack space. Adding one level of complexity pushes out other things that I'm thinking about. Using stack space for testing. I go to someone elses function and I need to understand their code and their tests before working on it.
- Fucks encapsulation, exposes internals.
- Good for academic, deterministic, small libraries (those that arn't hard to debug). Sucks for large problem spaces (games) and non-determinism(games, image processing, UI).
I don't think it's a coincidence that TDD's platform is java. Java is designed to make it harder for programmers to write bad code. TDD makes it even harder... but perhaps you want to write good code?
One thing that did come out of the evening was mock classes - super test friendly prototypes. Makes it even harder to write bad code.