Managing the maintenance burden of unit tests [closed]

Question

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 broken_unit_tests 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.

How do I find my way out of this dilemma, and start welcoming changing requirements like I'm supposed to?

Answer 1

Keeping the aspect of Programmer Discipline aside... (it's a personal thing if you're okay with checking-in without doing a buddy build or without fixing all the tests. Agile assumes high discipline.. and Courage&Support to stay on the right path under Pressure :),

If you find that making a single change fails multiple tests, its a smell that something is wrong with your tests. Fragile Tests are common when you start out with TDD... if you spend more time fixing your tests than fixing your code... stop, breathe and reflect. Fix the disease rather than the symptom.
If you have some code snippets, we could discuss. As it stands I dont think I can help you out much...
Guideline: A test should fail for only one reason.. Conversely every failing test should point out the exact unique location of the defect. Two tests should not fail due to the same change. Unless you're making architecture level sweeping changes, this should be rare.