Hi Richard,
Thanks for sharing this feedback. It's great to hear that you've been finding NCrunch so useful and I hope for the chance to continue to make it even more useful for you in future :)
There are plans in V2 of NCrunch to introduce custom grouping options in the Tests Window. This has been an intended feature area for a long time, as simply grouping tests by project/fixture isn't always ideal for every situation. The extent of the grouping options available will depend upon the time available, but grouping by status was one of the concepts being eagerly looked at.
There are, unfortunately, some big technical constraints around what NCrunch can handle inline at class level. This is because NCrunch itself is language agnostic and does not have an understanding of the raw source code itself. In order to perform class level actions inline, there needs to be some way to identify where to attach these options in the source code. Currently all method-level actions are being performed using debugging information output from the compiler (which is not available at class level). The new Roslyn C# compiler is expected to open many doors for this sort of thing in future, so a feature like this is something best examined as part of a long term plan pending the extension of NCrunch into new feature areas.
The integration/system tests you've described are a very common problem and in my experience, most projects have their fair share of these. Moving much of the complexity of these tests into smaller, more isolated tests is definitely a worthy goal, but there is no real substitute for a good end-to-end test. The best way to handle this is to mark these tests with a specialised category that you can then ignore from automatic execution using a custom
engine mode. NCrunch will then run these tests only when manually commanded to do so, while still running the faster areas of your suite automatically. When properly configured, NCrunch works very well with long running tests because of its ability to workspace them separately and run them in parallel while you are working on other things.
The processing queue does show which tests are being executed at any point in time (at task-level granularity). It's unfortunate that this view tends to be very noisy - especially if you are working on a large project with many thousands of tests. I have a hope to add some filter options here in V2 if there is time to do so.
Thanks again for the great feedback. It's always useful to hear how people are making use of NCrunch and the challenges involved in configuring it with complex solutions.
Cheers,
Remco
