Break down coverage by test-type

We have tests; unit (which don't hit a database/network/filesystem or run slowly, and use mocking to reduce coupling on hard dependencies) and integration (which aren't unit tests). We have a build task to run NCover and NCoverExplorer to produce reports. These reports show the coverage of our code, obviously; however, there's no way to see information (in the current reporting, as far as I could see) to the effect of "this class is 60% covered by unit-tests, and 80% covered by integration tests". Our two different types of tests are split between two assemblies (but that's achievable through different means with different test frameworks; we're using xUnit 1.0.3 and haven't seen a mechanism similar to MbUnit's Category attribute...?).

It would be really nice to be able to see, in the same report (well, we think so, anyway! ;-) ), coverage due to the different types of tests. Personally, I think a reasonable way to visualise this would be: * to show the report, by default, as now (as in, a tree of namespace-type), but allow each coverage bar (which, at the moment, displays the coverage from the merged reports) to be expanded (and, critically, not indented when that happens, so that an easy by-eye comparison can happen between merged-coverage and by-test-type coverage) to show coverage as caused by the different types of tests; when expanded, the aggregate bar should be on top, followed vertically by a bar for each coverage total caused by each test-type (essentially, a bar becomes a block of bars) * to provide an expand/collapse-all control at the top of the report * to provide an expand/collapse-current-node control on each node (aside - have you seen the reports Gallio produces for test-results?) * to provide extra numerical data in the right-side column that currently holds sequence/branch-point coverage for reading as opposed to visualising, when a node is expanded.

This would allow us to tell whether we're relying on integration tests or unit tests for test coverage of various modules. This in turn would allow us to decide where to focus our efforts on test coverage, because as people have written, unit-tests that mock out dependencies are easier to maintain and provide quicker feedback than integration tests with hard-dependencies. Of course, integration tests are a better indication of whether the system is working as a whole; it's a trade-off...

RE: Break down coverage by test-type

Thanks for the great feature request! I've added it to our tracking system, we will review and discuss a resolution as soon as we can.

Stephen Ward