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

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?开发者_如何学Go 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!

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.

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.

In brownfield projects, it may not be worth the effort to to reach any absolute threshold, neither for source code metrics, nor for test coverage. In code quality, the most suggested approach is known as the boy scout rule, i.e. leave the code (the camp) a little cleaner than you found it. This way, the code will gradually improve.

In testing, the situation is similar. Core functionality has been used productively for a long time, so there is a low probability for bugs in this area. Research has shown that recent changes have five times the bug probability compared to the system as a whole. Therefore I suggest starting with recently changed code.

You can use information from the source code management system to identify changes, or e.g. compare the most recently built binaries with the last production release. In order to further narrow down the scope, you may ignore changes that solely originate from refactoring. You can then focus your tests on these areas. An example for this approach is sketched in this blog post. Since the idea is agnostic of the actual test methodology, it can even combine results from unit tests and manual regression tests.