July 8, 2008
Identifying High Risk .NET Code With NDependThat clever chappy who markets the .NET metrics tool NDepend has added a very useful feature. You can now import unit test coverage reports from NCover into a code analysis project, and compare test coverage with other bug-influencers like code complexity.
So you could, for exampe, write a code quality constraint that warns you if NDepend finds any methods that have low or no coverage and high cyclomatic complexity (along the lines of the CRAP4J tool). This might highlight methods that are likely to be buggy because:
a. There's more that could be wrong with the code, and
b. There's less chance of our tests detecting such defects
If you wanted to especially smart-arsed about it, you could also include method rank (the extent to which other methods directly or indirectly depend on a method) and pull off a report of methods that are:
i. Likely to be broken
ii. Unlikely to be known to be broken
iii. Likely to have a wider impact if it is broken
If someone were to ask me which methods to prioritise in improving test assurance, such a list might prove very enlightening.
There's also - and I haven't tried this yet, so maybe it can't be done in NDepend today - the tantalising possibility of measuring test coverage of new or changed code, since NDepend allows us to compare two versions of our assemblies. When you're working on legacy code, and you want to be sure that developers are being genuinely test-driven even though the overall coverage might not be improving much, this could be useful information to have to hand.
Posted 6 days, 22 hours ago on July 8, 2008