Determining which classes would benefit most from unit testing?

Question

I am working on a project where we have only 13% of code coverage with our unit tests. I would like to come up with a plan to improve that but by focusing first on the areas where increasing coverage would bring the greatest value. This project is in C#, we're using VS 2008 and TFS 2008 and out unit tests are written using MSTest.

What methodology should I use to determine which classes we should tackle first? Which metrics (code or usage) should I be looking at (and how can I get those metrics if this is not obvious)?

Answer 1

I would recommend adding unit tests to all the classes you touch, not retrofitting existing classes.

Most of the advantages of unit testing is in helping programmers code and ensuring that "Fixes" don't actually break anything, if you are not adding code to a new section of code that isn't every modified, the benefits of unit tests start to drop off.

You might also want to add unit tests to classes that you rely on if you have nothing better to do.

You absolutely should add tests to new functionality you add, but you should probably also add tests to existing functionality you may break.

If you are doing a big refactor, consider getting 80-100% coverage on that section first.

Answer 2

The biggest value of a unit test is for maintenance, to ensure that the code still works after changes.

So, concentrate on methods/classes that are most likely / most frequently changed.

Next in importance are classes/methods with less-than-obvious logic. The unit tests will make them less fragile while serving as extra "documentation" for their contracted API

Answer 3

For some good statistics and deterministic querying of certain methods you could definitely look at NDepend: http://www.ndepend.com/

NDepend exposes a query language called CQL (Code Query Language) that allows you to write queries against your code relating to certain statistics and static analysis.

There is no true way to determine which classes might benefit the most, however by setting your own thresholds in CQL you could establish some rules and conventions.

Answer 4

Arrange all your components into levels. Every class in a given level should only depend on components at a lower level. (A "component" is any logical group of one or more classes.)

Write unit tests for all your level 1 components first. You usually don't need mocking frameworks or another other such nonsense because these components only rely on the .NET Framework.

Once level 1 is done, start on level 2. If you level 1 tests are good, you won't need to mock those classes when you write your level 2 tests.

Continue in like fashion, working your way up the application stack.

Tip: Break all your components into level specific DLLs. That way you can ensure that low level components don't accidentally take a dependency on a higher level component.

Answer 5

In general unit tests are a tool to protect against regression and regression is most likely to occur in classes with the most dependencies. You should not have to choose, you should test all classes, but if you have to, test the classes that have the most dependencies in general.