Home/ Questions/Q 541917
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T10:23:33+00:00

Let me qualify this question. I’m working on a classic ASP.NET application (Web Forms)

  • 0

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0