I enjoy Test Driven Development (TDD) for the value it brings out in both my professional attitude (affirmation that tests are important) and my code (driving out design ideas and forcing the code to be easier and faster to unit test). There are times where I get frustrated at not being able to write code as fast I as want (and believe me, typing speed is not the issue – perhaps it’s Java’s verboseness?), and you get lost in all the syntactic aspects of the programming language, thinking about proper class responsibility, maintaining consistency throughout the entire application, and trying to improve upon what is there.

I have witnessed it far too frequently (and also sometimes succumb to) the comfort provided when all tests pass, with a natural conclusion being that all things in our application are perfect. Sometimes I make the mistake of assuming that other parts of the system are just as well tested, and have not changed beneath my feet.

Though there are many (yes, unfortunately not all) of us who believe that the tests we write and automate are important, let us never forget the ultimate acceptance tests for the system we write that our end users may (or may not) give us… their happiness.