It would be helpful to have NCrunch treat (or at least report) decreases in code coverage as "fail".

For example, supporting an attribute that marks a project/class/method as "100% code coverage required".

Or a larger flag such that any code coverage drop is a "failure". This would be a bit trickier to support as it may need to be include a way to identify a baseline. And it may be helpful to distinguish between coverage for old code vs coverage for new code.

I think starting with a numeric attribute indicating the required coverage would give the biggest ROI -- developers can update the attribute accordingly, and build pipeline steps can enforce requirements.

It would be useful if there was an AlwaysImpactedAttribute that could be attached to a test method so that it always executes when a code change is made.

The use case I am thinking of occurs with Automapper. We have a test that executes AssertConfigurationIsValid(), but when the engine mode is in "Run Impacted Tests Automatically" NCrunch will not detect that this test needs to be run whenever we make changes to the models in the solution.

If I could put an attribute on that test method that says 'always run', I could continue to use the "impacted only" engine mode but always have the Automapper test be up to date.

Currently the test results appear as a block of text within the "NCrunch Tests" window. When compared to the built in display of test results in TestExplorer (im using VS2017), it feels rather raw and perhaps could be improved.

Im not saying to get rid of the raw text output (we all have our preferences), but to have an option to format the display of results to allow the result of a test to be clear and distinct from the full result text. So, instead of:

Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: Assert.AreEqual failed. Expected:<2>. Actual:<1>. Some random failure description i typed in as the 3rd param of AreEqual
at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.HandleFailure(String assertionName, String message)
........

which is more than you need to read at times.. so id like to see something along the lines of:

Assert.AreEqual failed.
Expected:<2>.
Actual:<1>.
Some random failure description i typed in as the 3rd param of AreEqual
......

perhaps a gap then the stack trace. the first line could be a hyper link to the failing line (instead of the last line of the result text).

We're looking into setting up an NCrunch node farm. This would be used by developer machines but it would also be used by the build server. When the build server goes to run tests, we'd like to have those test tasks take execution priority over test tasks coming from dev machines. Is this possible?

From Remco: Presently it isn't possible to control this. The grid nodes operate on a round-robin type request system that treats every connected client equally. The only way to ensure priority for the build server given NCrunch's current feature set would be to set aside nodes specifically for the server only.

It makes sense why you would want to give the build server priority.

I usually organize my Test window by project. I sometimes want to see the green tests in the Tests window to keep a consistent view as tests alter between red and green, and to remind myself of which subset of tests I'm currently monitoring. However I almost never want to see all the Build Successful messages there for projects that don't contain any tests (in my case, that's dozens). If a build fails, I would still want to see it, but otherwise all that green is just a lot of noise to me.

Is there a way to suppress those Build Successful messages for projects that don't have any tests in them?

I would love a keyboard shortcut to reset Ncrunch.
I don't know if its possible to assign it myself, could not find it in customize keyboard.
maybe the disable and (re)enable Ncrunch sequence is the same as a reset,...?

Use case:
- I open a solution in VS 215
- ncrunch starts and reports green on risk/progress bar
- I get latest version for a solution from sourcecontrol
- build fails because there are not new nuget packages referenced.
- I build the solution which does a nuget restore
- then I have to open the ncrunch tests window (using keyboard) and then navigate with the mouse to the reset button to click it.
- after a while ncrunch reports green :-)

On unit tests where you check for expected exceptions the end of the method can't be reached, so the line with the closing curly bracket keeps uncovered.

Placing a no coverage comment directly after the closing curly bracket works.

If you reorganize your code by using automated tools such like CodeMaid or ReSharper, the no coverage comment does not stay after the designated line and you have to adjust that by hand again (and again...).

Introducing a suppression comment like
"// ncrunch: no coverage next"
which can be placed directly over the closing curly brackets would be moved as expected, because it is inside the code block (the method) which is moving.