Test Driven Development

Test Driven Development triggers different feelings in a developers mind. I heard from many good developers that its a waste of time, others are obsessed with it.
My position on it is: TDD should be used in a pragmatic way and always under the magnifying glass of the ROI.



If a manager asks me why a team should use TDD, I bring it down to the following reasons:

  • it brings two clients right away, the test and the using API itself, that way you create a much more user friendly API
  • TDD makes it possible for a developer to focus on a very specific piece of code at one time
  • in heavy java environments it speeds up the development cycle
  • it enforces the divide and conquer strategy by asserting many constraints on a specific small piece of functionality
  • it creates a robust safety net to assert anytime that your code still behaves as expected, specifically after many changes are done
  • it resolves the need to design a complicated algorithm upfront and lets you develop “outside in”
  • a test suite can be the perfect contract between multiple teams making distributed development much easier

I seldom meet teams that do it properly. Most of the time there are single devs who do it alone.
The main reason for it is the lack of knowledge about TDD and the lack of passion about writing code.



There are major enemies of TDD, that I specifically want to pick out:

  • building up white box tests
  • lack of knowledge about the testing pyramid
  • too many useless tests lowering the motivation of the team to deal with them
  • missing a proper fixture framework and working with wrong fixture DSLs like CSV, XML or YAML
  • mocks overuse
  • general lack of TDD understanding and no team oriented thinking in regards to TDD

…and here some blog posts I wrote about TDD and I am sure more are to come in the future:


3 years beeing a TDD fan

For around 3 years ago I came over the TDD approach and got very excited by it. It…