1. 4
  1.  

  2. 5

    I ship production code and I do not practice TDD. I do test my code though.

    The problem I have with *DD is that they take some action and turn it into the cure-all for producing good code. What I care about is a good API. I don’t really care how I or any of my colleagues got to the good API. And I care that the API fulfils its properties.

    Writing good APIs is really only about reusing a few themes over and over again, so it becomes pretty easy from just looking at an API if it is testable, and if it’s good. If *DD is a useful tool to force you to find those themes each time, then use it. The basic theme is: reuse control flow by means of callbacks.

    1. 1

      Once anything becomes a religion it ceases to be good science. But *DD can be a marvelous system for developing the level of confidence and skill you’re describing that you enjoy.