Please add an option to allow sorting by natural code order in the test window. So the tests appear in the same order in the test window as they do in the source code file.

Tests are typically written in roughly increasing order of complexity and dependency - in general, I would almost always want to fix a test that appears first in a source file before those that appear after it.

Tests are also often (very) loosely grouped together by position in the file - related tests will be next to each other, and it would be helpful to reflect that in the list of tests.

More details: https://forum.ncrunch.net/yafpostst3041Is-it-possible-to-list-tests-in-code-order--in-the-test-window.aspx

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…

My MsTest project has a simple .runsettings file like this:

<RunSettings>

    <TestRunParameters>

        <Parameter name="foo" value="bar" />

    </TestRunParameters>

</RunSettings>

These parameters are supposed to be injected at runtime into all test classes TestContext property

public TestContext TestContext { get; set; }

Then you can use that property like this:

[TestMethod]

public void TestMethod1()

{

    Assert.AreEqual("bar", TestContext.Properties["foo"].ToString());

}

Unfortunately the this doesn't work when running NCrunch as the properties are not picked up. There doesn't seem to be a way to specify the path to the .runsettings file in NCrunch settings.

When running via Visual Studio or on Azure DevOps this works fine.

I'd prefer that runsettings (at the very least, just the TestRunParameters) were supported rather than environment variables, as that is the current recommended approach to provide parameters to a test project.

Currently, the selection of which projects are built is opt-out. That is, all projects are monitored and built unless you set the "Ignore completely" flag explicitly on a project in your configuration.

It would be nice to have something that works more like building from the GUI or the command-line would: an opt-in feature.

In this proposed new mode of monitoring-selection, projects would still be monitored, built, and tested exactly as they are now. The only difference would be that all projects would be ignored completed and you would have to explicitly choose a project to be monitored. Obviously, any project that is a direct or indirect dependency of an opted-in project would need to be monitored as well.

This would allow you to make more intention-oriented selections fo what to build and what not to build, because you would focus on the things you do want and allow anything not required for those selections to be automatically ignored.

I've worked in a number of scenarios where we had a subset of tests which would be better classed as "system tests". I.e. they covered a large amount of system functionality and took a considerably amount of time to run (sometimes minutes). Running these as conventional unit tests under Ncrunch, triggered by every editor change is overkill but OTOH the Ncrunch UI is really nice and its ability to automatically run things is very helpful. It would be useful if these tests could be treated in a different way to normal units tests, e.g. only run on a scheduled basis (subject to editor changes) at a low priority with a larger timeout than that used for unit tests.