It's possible to do this using configuration.
You can assign a category to your integration tests, then exclude them from your engine mode's 'Tests to execute automatically' using the 'Customise engine modes' option - https://www.ncrunch.net/documentation/concepts_engine-modes
On the surface this appears to be a very simple feature that could be provided with a few hours work, so I understand the frustration at why it hasn't been delivered yet.
Unfortunately, it's actually far from simple. NCrunch captures code coverage information in a document line form, where IL-based tools like NDepend need data in type/method form. So the data would need to be mapped between structures, using extra information that would need to be extracted by NCrunch during instrumentation. That means loss in performance for each run.
Such problems can of course be resolved, but this need to be put in the broader context of everything else happening on the project. This feature request currently has only 5 supporters, which gives it little weight compared to relatively easier to implement features that benefit far more people. Over the last two years we have also had to deal with an entire re-write of the .NET platform (.NET Core) and all of the chaos that's come with it.
At the moment no feature in NCrunch exists that can export coverage in partcover/opencover/sonarcube/dotcover format. This is because NCrunch's code coverage is flat over the source (i.e. files and directories) rather than IL-indexed (classes/methods).
We've been looking at ways to convert between these, though there are performance implications. At some stage this will likely happen.
This behaviour is controlled by the following configuration setting: http://www.ncrunch.net/documentation/reference_global-configuration_auto-adjust-clashing-marker-colours
Thanks for this. I've updated the website based on your feedback.
This feature does already exist, but it is controlled on the grid node itself (not the client).
To make use of it, you need to use the Grid node configuration tool (NCrunch.GridNode.Configuration.exe) and assign a Node Id (Name) to the grid node. If no value is specified for this field, the grid node will use its network name instead (which is what you're seeing right now).
Der Albert has also suggested stack traces should be cleaned up for async/await - http://forum.ncrunch.net/yaf_postsm11731_Make-async-await-Stacktrace-readable.aspx#post11731
It's hard for me to say never on this, because you never really know, but what I do know is:
1. It's proving very hard to keep up with eco-system changes, because NCrunch is so integrated with so many toolsets, and many of these are moving targets. This is a strong reason to avoid integration with additional toolsets if possible.
2. There doesn't seem to be huge demand for NSpec, relative to the other frameworks.
3. We hope to eventually implement an API or SDK allowing people to build atop of NCrunch and implement their own test frameworks or adapters. I can't promise yet when this will be available, but NSpec would be an ideal use case for it.
4. We don't expect to implement an NSpec adapter ourselves in the foreseeable future.
There are built-in shortcuts to do this via the menu system.
Alt+U, S, 1
Alt+U, S, 2
Alt+U, S, 3,
There are no hard coded shortcuts to do this directly because the engine modes are entirely dynamic, and under Visual Studio shortcuts need to be statically configured.
This can be done with custom configuration.
Since v3, it's possible to override many of the UI setting of NCrunch inside the engine modes. A tidy way to know which engine mode is selected is by customising your engine modes so that they each override the 'Marker style' configuration setting. In this way, you can have a differently shaped marker for each engine mode.
Sorry there are no plans to introduce this in the near future.
Support for C++ would require a whole new build, instrumentation and runtime system. It would require a significant effort to both introduce this support and maintain it. At present, there does not appear to be a strong enough business case to warrant the cost of this.
At the moment, there are no plans to implement this in the immediate future.
Despite the number of people that I'm sure would love to see this, it's unfortunately also the largest feature ever requested for NCrunch. Support for Rider would require rewriting ~30% of the product in Java, and would naturally include a promise to simultaneously support ALL future versions of Rider in the same way that VS is currently supported. So we'd basically be looking at 1 year+ of development up front, plus a massive maintenance burden that would likely be impossible to carry with the existing structure of the NCrunch business.
I'm going to leave this feature request up here rather than reject it outright, as it's still useful to know how many people want this ... but please understand that at the moment, I can't deliver what is being asked for.
Use of the NCrunch Category attribute is only necessary if you're using a test framework that doesn't have its own category attribute equivalent (NCrunch will detect categories of tests via framework integration).
Once you've categorised the test, all your need to do and update the engine mode to set the 'Tests to execute automatically' filter inside this engine mode.
It's possible to get the engine to do this without needing a new feature.
You can add a special category to tests that use Automapper, then modify the 'Run Impacted Tests Automatically' engine mode to also run tests that are marked with this category, in addition to the impacted tests.
Interestingly, this seems to be a regression in v3.3.
It did actually work in v3.2.
I'm not sure what has changed to break this, but I'm planning to investigate and release a fix for it soon.
So this feature is planned, at least, in the sense that I expect it will eventually be delivered. It's hard for me to make any commitments on the timing of its delivery because it is a very large feature and dependent on many other areas of the product to be ready for it.
The design of this SDK/API will depend very much on the sorts of things people want to do with NCrunch. I understand that being able to introduce support for additional test frameworks and access code coverage data would probably be top requests here.
Can anyone else share any ideas for plugins they'd like to write?
Do you see long startup times for NCrunch consistently?
I ask because NCrunch actually does very little on startup. Almost all of the processing cost for NCrunch happens when the Engine Host process launches, which is outside of Visual Studio.
Thanks for the extra details. Have you noticed anything else in the NCrunch UI that seems a bit off? Or is it just the engine mode filter window?
This is defective behaviour. Can you share any more information about your display settings and DPI? If I can reproduce it, I may be able to introduce a fix.
There is a key difference between parallelisation in xUnit vs NCrunch: xUnit runs tests in parallel within the same process (i.e. different thread), where NCrunch runs tests in parallel in different processes (i.e. different process).
This means that a test that cannot be parallelised in xUnit may still be parallelisable using NCrunch. For example, if a test is making use of code that isn't thread-safe and is making use of static state, it can't be parallelised using xUnit, but can still be parallelised using NCrunch. If a test is making use of a shared resource on the file system, it cannot be parallelised by either.
This makes it unwise for NCrunch to simply assume that a test fixture marked with an xUnit collection cannot be parallelised. Really, these are two completely different mechanisms and the only way for NCrunch to know whether the test should have parallelisation restrictions in place for cross-process parallelisation is through specialised attributes targeted towards NCrunch (i.e. ExclusivelyUsesAttribute).
Have you tried using the 'Sliding build delay' global configuration setting?
I ask because this seems very similar to what you're requesting.
Having NCrunch trigger when a line is completed can be subjective - how would it know when a line is finished?
If I understand this request correctly, NCrunch should already be doing this.
In the Tests Window, you can choose to 'pin' the test fixture itself. When this is done, you should see the little pin appear next to the fixture and all its child tests. If any new tests are added to the fixture, they will automatically be pinned.
Note that this only works at fixture level - it isn't currently possible to pin a namespace or project.