title: Why is it a best practice to always unit test the smallest possible unit of code? I find those tests will never survive a refactoring
body: <p>I've been a practitioner of test driven development for several years, and overall i'm happy with it.  The one part that I don't yet understand is the idea that you should always be unit testing the 'smallest possible unit'.</p>
  
  <p>Part of the idea of unit testing seems to be to allow you to refactor with confidence that you won't break anything.  However, I find that tests which test very small pieces of code will almost never survive these refactorings, the code always changes significantly enough that small unit tests just get thrown away and new tests are written.  It is the tests that cover larger pieces of functionality that seem to give the most value here, since the higher level interfaces don't change as often.</p>
  
  <p>And for trivial refactorings, like moving methods around, those are just done via an IDE, and since i'm using a staticly typed language, I've never run into a situation where the IDE isn't able to do the refactoring perfectly.  </p>
  
  <p>Anyone else have similar or opposite experiences?</p>