title: Tips on how to write refactoring-friendly unit TDD tests
body: <p>I've been working on an ASP.NET MVC project for about 8 months now. For the most part I've been using TDD, some aspects were covered by unit tests only after I had written the actual code. In total the project pretty has good test coverage. </p>
  
  <p>I'm quite pleased with the results so far. Refactoring really is much easier and my tests have helped me uncover quite a few bugs even before I ran my software the first time. Also, I have developed more sophisticated fakes and helpers to help me minimize the testing code. </p>
  
  <p>However, what I don't really like is the fact that I frequently find myself having to update existing unit tests to account for refactorings I made to the software. Refactoring the software is now quick and painless, but refactoring my unit tests is quite boring and tedious. In fact the cost of maintaining my unit tests is higher than the cost of writing them in the first place.</p>
  
  <p>I am wondering whether I might be doing something wrong or if this relation of cost of test development vs. test maintenance is normal. I've already tried to write as many tests as possible so that these cover my user stories instead of systematically covering my object's interface as suggested in <a href="http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests" rel="nofollow noreferrer">this blog article</a>.</p>
  
  <p>Also, do you have any further tips on how to write TDD tests so that refactoring breaks as few tests as possible? </p>
  
  <p><strong>Edit:</strong> As Henning and tvanfosson correctly remarked, it's usually the setup part that is most expensive to write and maintain. Broken tests are (in my experience) usually a result of a refactoring to the domain model that is not compatible with the setup part of those tests.</p>