As much as I advocate automated testing, I've seen people waste time with it also by chasing coverage goals. If you are writing a new class or a new method, by

As much as I advocate automated testing, I've seen people waste time with it also by chasing coverage goals. If you are writing a new class or a new method, by all means, write tests for it. Getting tests around all of your currently existing code, however, is often a waste. You need to test the areas you are changing and the areas which are impacted by the change. In any code base, there are hotspots, places where both change frequency and complexity are high. Tackling those first with automated testing often gives you the best ROI. Remember, you aren't writing automated tests for existing code to find bugs, you're writing them to characterize the current behavior and get a behavioral invariant so that you can refactor and also so that you can add features with the knowledge that you haven't changed the old behavior in unexpected ways.