Useful/Realistic code coverage goals for a brownfield ASP.NET application

Question

Let me qualify this question. I'm working on a "classic" ASP.NET application (Web Forms) that doesn't use Model-View-Presenter and was not written using TDD. It's also using an antiquated data access strategy (hand written DAO layer that invokes stored procs to populate and persist objects) that is unlikely to be upgraded to an ORM despite my strong desire to do so.

Since I took over development of the application, most new features have been implemented using TDD. That still leaves the old code base, DAL layer and entire UI as untested. Before I figure out how far away the application is from that mystical 70% code coverage goal, I'd like to get clarity around what kind of code is typically included when determining code coverage.

Business logic code is clearly included, but how about WebForms code? Additionally, how about data access code? As mentioned above, our data access layer uses stored procedures to populate object graphs and persist them back to a DB. Is object persistence and re-hydration something that should be included?

I apologize if this question is too open ended, I just feel a little overwhelmed and confused about how to get this brownfield application in better shape.

Thanks!

Answer 1

Don't set targets for code coverage or any other code metrics. It usually turns out that hard targets do more damage than good.

If you give other developers hard code metric targets they will just game the targets if they don't understand the underlying reasons for the target.

As a parallel example, you will not believe how many "Keep FxCopy happy" code comments I've seen in my career.

If you set a hard target for test coverage, lazy developers may skip writing null checks etc. because it decreases their coverage if they don't write the corresponding tests. The end result is poorer code quality.

Conversely, developers who understand the benefits of TDD don't need the target because they'll do the right thing regardless.

That doesn't mean that the code coverage metric is irrelevant. It is very relevant, but instead of setting a hard target, I think you should have a rule that says that it must never decrease.

So measure it regularly and make sure it's only going up. That doesn't preclude you from having your own personal goal, but don't set a hard target.

Answer 2

Code coverage doesn't have a high correlation to application stability. Rate of influx of bug reports (and the bug's severity) does have a high correlation to application stability.

When I talk about code coverage, I include absolutely everything and just assume 100% is unrealistic. There are probably many different opinions on the subject, so it seems pretty subjective to me.

If I was in your position, I would be more worried about getting manual and automated regression test bases built before worrying about code coverage.