I am not going to say that some of these testing religions don't have a place, but mostly they miss the point. By focusing on TDD or "code coverage" the essenti

I am not going to say that some of these testing religions don't have a place, but mostly they miss the point. By focusing on TDD or "code coverage" the essential questions are missed. Instead of focusing on methodology instead I recommend asking yourself simple questions starting with: 1. How do I meet my quality goals with this project (or module of a project)? This is the root question and it will lead to other questions: 2. What design and testing practice is most likely to lead to this outcome? 3. What is the pay off value for this module for a given type of testing? 4. How can I be confident this project/module will continue to work after refactoring? etc. etc. I have used TDD style unit testing for certain types of modules that were very algorithmic centric. I have also used integration testing only for other modules that were I/O centric without much logic. I personally think choosing a testing strategy as the "one right way" and then trying to come up with different rules to justify it is exactly inverse of how one should be thinking about it (top down vs bottom up design of sorts).