title: Philisophical Questions about Test-Driven Development
body: <p>I have been perpetually intrigued by test-driven development, but I can never follow through with it when I try it on real projects.  I have a couple of philosophical questions that continually arise when I try it:</p>
  
  <ol>
  <li>How do you handle large changes?  When it comes to testing single functions (some parameters, a result value, few side effects), TDD is a no-brainer.  But what about when you need to thoroughly overhaul something large, e.g. switching from a SAX parsing library to a DOM parsing library?  How do you keep to the test-code-refactor cycle when your code is in an intermediate state?  Once you start making the change , you will get a bevy of failed tests until you've fully finished the overhaul (unless you maintain some kind of mongrel class that uses both DOM and SAX until you're done converting, but that's pretty weird).  What happens to the small-step test-code-refactor cycle in this case?  During this whole process you will no longer be moving in small, fully-tested steps.  There must be some way people deal with this.  </li>
  <li>When testing GUI or database code with mocks, what are you really testing?  Mocks are built to return exactly the answer you want, so how do you know that your code will work with the real-world database?  What is the benefit of automated tests for this kind of thing?  It improves confidence somewhat, but a) it doesn't give you the same level of confidence that a complete unit test ought to, and b) to a certain extent, aren't you simply verifying that your assumptions work with your code rather than that your code works with the DB or GUI?</li>
  </ol>
  
  <p>Can anyone point me to good case studies on using test-driven development in large projects?  It's frustrating that I can basically only find TDD examples for single classes.</p>
  
  <p>Thanks!</p>