title: Managing the maintenance burden of unit tests
body: <p>Coding test-first, I find that perhaps 3/4 of my code is unit tests; if I were truly extreme, and didn't write a line of code except to fix a failing unit test, this ratio would be even higher.  Maintaining all these unit tests adds a huge amount of inertia to code changes.  Early on, I suck it up and fix them.  As soon as there's pressure, I end up with a <code>broken_unit_tests</code> directory to revisit 'when there's time'.  It feels like TDD is putting in high coverage too soon, before the design has had time to crystallize. </p>
  
  <p>How do I find my way out of this dilemma, and start welcoming changing requirements like I'm supposed to?</p>