Great article. I enjoyed how well the author builds his case and argues for it rather reasonably. While I do disagree with his article on the whole, I do agree

Great article. I enjoyed how well the author builds his case and argues for it rather reasonably. While I do disagree with his article on the whole, I do agree that TDD is not the end all be all. There is good TDD and there is bad TDD. TDD is a very general practice and what really defines your tests as good or bad is really your OOD skills. One thing (really two things that work hand in hand) that I've found to augment my OOD skills so that I write better tests and better software is domain driven design and behavior driven testing. Using these techniques together has helped me to learn to ask better questions of my domain experts, create more decoupled and flexible software, as well as solve that age old how do I test the UI when it isn't already in an MVC framework (the correct answer is to treat it or portions of it as their own domains imo). This is the kind of article that provokes thoughtful discussions by having a well thought out opinion and not just blabbering the first idea that comes to mind. Thanks and keep it up!