What are some common pitfalls of Test Driven Development?

Question

I'm new to test driven development. What are some recommendations when writing test cases as well as to avoiding common mistakes for TDD?

Answer 1

In TDD you write the minimum amount of code to pass the test case. That test case, of course, should only be testing at a unit level. You want to test individual pieces, so you write test cases to cover limited functionality(mainly 1 feature).

Your test cases will end up acting as documentation for your system and low-level regression testing. TDD is great because any future code changes can (not will) alert you to bugs.

One of the hardest things to explain is that TDD does not replace your testing. It is simply a development process to build testing right into the software. Test Early, Test Often. :D

Answer 2

• Make each test very small and focused.
• Avoid making tests depend on each other, either explicitly or implicitly. Dependencies among tests are a path to pain, expense, fragility, and complication. I have never seen an exception to this. Ever.
• Make each test express its intent very clearly.
• Pay attention to failure messages. Make each failure message as helpful for diagnosis as you can.
• Involve as little of the system as you possibly can in each test. The more parts of the system you involve in a test, the more ways it can fail, even if the functionality that the test really cares about is working.
• Do not skimp on the refactoring. It is the refactoring that will keep your code (including the tests) easy to understand and change
• As you write code to pass the tests, consider cheating as hard as you can. Do the stupidest (or easiest) thing you can do that will pass the tests. Later, in order to make the code less stupid, you first demonstrate its stupidity by writing a test that the stupid code can't pass.