Integration Test Detection Metric
Some of the pitfalls of Integration tests are listed in the docs (https://www.ncrunch.net/documentation/guides_integration-testing) and identifying when they've been accidentally introduced into the test suite would be a nice feature.
An Integration Test Detection could be a metric or report that identified unit tests that are executing a large number of production code classes. In an ideal unit test the number would be 1, the class/system under test. For tests that are tightly coupled to other classes the number might grow quickly. These are problem areas that might need some design work to reduce the coupling or maybe just write the test in a better way (subbing and mocking when possible). Either all tests could be included in the report, or all tests with a count greater than 1, and it could be ordered with the largest class count at the top (hopefully excluding test project/classes in this count?).
Optionally, provide a total class count filter so we can configure it so only show offenders over N classes. Maybe options to exclude enums or similar types that don't indicate there are any issues but might unnecessarily bloat the total count could be excluded.
Since NCrunch ‘crawls’ through the code and already keeps a tree of execution paths it seems this wouldn’t be too far fetched of a metric to report on…