- True TDD requires 100% test coverage of the code the developer using TDD has written or altered. I've seen the reports from companies or organizations claiming they do TDD that aim at least 60%. That isn't true TDD, in the Kent Beck definition of the term. That's not to say these people are wrong. In fact, because they have a better balance between test code and production code, they can change functionality of code more easily.
- Many developers attempting to practice TDD don't write the tests well enough to cover every possibly argument/configuration for the various methods they were testing. That's not TDD.
- Many developers attempting to practice TDD won't test trivial methods like getters and setters. That's not TDD.
- Many developers attempting to practice TDD write tests that duplicate the parts of the code being tested. While there are valid reasons for this, it results in frustration for the developer who needs to change 20 tests just to change one bit of functionality. Avoiding this in many cases can take an enormous amount of discipline and time, ensuring proper modularization, mocking, and refactorization of both production code and tests.
So, why do people claim to be doing TDD that aren't? Because there is not a good term out there that everyone knows of for just writing tests before writing code some of the time, duplicating functionality of tests, and leaving out functionality tested by many tests.
In some way, writing and maintaining tests is a lot like auto maintenance. TDD is like keeping your car in pristine condition. It is super-shiny because it is always just-washed and sparkly, and it runs like a champ. But in the end, the primary reason for the car is to get you from point A to point B.