How to determine which code in a project/solution is the most often used?

Question

If I have an existing solution containing multiple c# projects, are there any static analysis tools that can help me determine which areas of code are the most often used?

I'd like to use this information in order to determine which areas should have their test coverage ramped up first.

I've looked at some static analysis tools already, but they mostly seem to focus on things like complexity, coding conventions, code duplication etc.

Alternatively, if there aren't any analysis tools available that can do this, do you have any advice about how to determine which code I ought to focus on testing first?

Thanks!

EDIT: Just to clarify, what I'm looking for isn't code coverage. I'd like a rundown of which parts of my application are most often used, so that I can in turn focus on improving the coverage in those areas. I'm trying to avoid just writing tests for areas that don't yet have any, as they may be edge cases that aren't often executed.

Answer 1

NCover

Answer 2

Code coverage appears to be what you want.

NCover is a popular code coverage tool for .NET, if you can afford it.

Answer 3

If you want to see just what is used: SD C# Test Coverage Tool

If you want to see how often it is used: SD C# Profiler Tool

Answer 4

Even static analysis tools which do try to figure out what happens at run-time do not usually try to estimate how often a piece of code is executed. The subject is hard enough as it is!

But dynamic analysis tools (e.g. profiling tools that either rely on transparent instrumentation of the code or use sampling) can tell you, after one or several "typical" executions (you provide the entries that you judge typical), how often this or that function was executed.

See Profiling (computer programming) on Wikipedia.

Answer 5

If I understood the question right, you are looking for a profiler. Give EQATEC Profiler a try. It's free.

It's originally intended to profile an application before shipping (to detect bottlenecks by measuring execution time of methods etc.) so I'm not sure if it's suitable for an application in a productive environment. At least it changes your code for profiling purposes and that might be unwanted. You should check this out.

Answer 6

If coverage is not what you look for then you could look use two things:

1. As suggested a profiler and run predictive test scenarios.
2. Use performance counters which would end in a more permanent solution. These are quite difficult to implement but are helpful to diagnose performance deltas by analyzing the counters report. One way to implement them would be to wrap boundaries and manage counters from those wrap. Be wary that it's way much easier to integrate in a new project than in an existing one.

Answer 7

"Profiler" is what you're looking for; which you choose is up to you.

I've used HP's Diagnostic Server to do this, although it'd cost money. It'll tell me what methods are called how many times, and the average and worst-case time spent in them.

As an important safety tip, running a profiler will slow down the execution of your code; it's not ideal for a long-term installation into a production environment.