Code coverage numbers

We're using NCover.Console and NCover.Reporting.

coverage.xml is the generated xml file we pass in to NCover.Reporting.

Here's a sample of the command we run that creates the XML:

"C:\Program Files\NCover\NCover.Console.exe" //reg //w C:\TestResults //l "Coverage.log" //p "Automated Test Framework" //h "Coverage Report" //pm VSTestHost.exe "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\mstest.exe" /testmetadata:C:\Projects...\Office4.vsmdi /runconfig:C:\Projects...\TestRunConfig1.testrunconfig /resultsfile:"TestResult.trx" //it "CompanyName.*" /testlist:"Nightly Test Run"

and then

"C:\Program Files\NCover\NCover.Reporting.exe" "C:\TestResults\coverage.xml" /op:"Coverage Report\" /r:FullCoverageReport

And we get a nice report of the code coverage results.

However, the code coverage report only displays coverages for namespaces or files that the test code calls. For example, if I add a new file with a new class to my development project, but none of my unit tests call that class, the code coverage numbers will be identical to the last time.

Is there any way for the coverage numbers to include all of the code in a visual studio solution? Or is there any other way to make the coverage report report on code that isn't being exercised at all?

RE: Code coverage numbers

Are these new classes in the same assembly as other files that do have coverage?

We cover all dll's that are loaded into the process, meaning if the class is in any of those items, then it will have coverage. What we don't cover is items that are never loaded.

If the class is in the same assembly as other items that are called then you should verify the correct dll's are being called. The code numbers should change and the file should show up in the report.

If this is still an issue, please email support a zipped copy of the two coverage files and we can look into it.

Joe

RE: Code coverage numbers

Do you cover assemblies that are loaded dynamically at runtime via, for example, Spring.net? I seem to be getting 0% on those assemblies, but it might have to do with Spring not being able to instantiate its context properly when ncover runs the tests...

RE: Code coverage numbers

we do cover assemblies that are dynamically loaded. if the assemblies show in the coverage output and the coverage % is zero then that means that no code in the assembly was called.