I would like to make a point here on the fact that NDepend can answer what is maybe the most important question for an agile programmer:

Does added and refactored code is covered by tests?

There are 4 CQL default rules to address this need:

// <Name>Method where code was changed partially covered by tests</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE 
  PercentageCoverage < 100 AND PercentageCoverage > 0 AND
  CodeWasChanged 
  ORDER BY PercentageCoverage DESC , NbLinesOfCodeCovered , NbLinesOfCodeNotCovered 
 

// <Name>Method added partially covered by tests</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE 
  PercentageCoverage < 100 AND PercentageCoverage > 0 AND
  WasAdded  
  ORDER BY PercentageCoverage DESC , NbLinesOfCodeCovered , NbLinesOfCodeNotCovered 

// <Name>Method where code was changed not covered at all</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE 
PercentageCoverage == 0 AND CodeWasChanged ORDER BY NbLinesOfCode DESC 

// <Name>Method added not covered at all</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE 
PercentageCoverage == 0 AND WasAdded ORDER BY NbLinesOfCode DESC 

Of course, these rules can be refactored at whim, for example, to have just one rule that tells about all added or refactored method that are not covered by tests:

// <Name>Method added or refactored not fully covered by tests</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE 
  PercentageCoverage < 100 AND
  (CodeWasChanged OR WasAdded)
  ORDER BY PercentageCoverage DESC , NbLinesOfCodeCovered , NbLinesOfCodeNotCovered 

I wanted to make this point because I figured out that my friend Jason Gorman, which is certainly an advanced NDepend user, wasn't sure about this possibility (Identifying High Risk .NET Code With NDepend).

Why knowing if added or refactored code is covered is so important? Because if you can answer yes each time you are about to release a new version you'll end up after N iterations (N not too large) with a code well tested. As a consequence the number of bug will decrease, iterations after iterations, and a lot of time spent doing manual testing will be saved.

Is it pure theory? I can't answer, my common sense say yes it works, however I am not a theorist but a programmer. But I can attest that since we applied this methodology on the development of NDepend, the number of bug reported has decreased dramatically and our productivity increased significantly.

Concretely, these CQL rules sits on 2 features of NDepend that are:

Build comparison: the ability to compare 2 builds and to ask for which part of the code have been added/refactored/removed.

Test coverage data import from NCover™ or VSTS™ the possibility to ask for code fully, partially or not covered by tests.

And as all NDepend features, this possibility to know about refactored/non-tested code can be harnessed from the VisualNDepend UI but also from the CI build process by customizing NDepend project properties, as shown below: