Hi Will -

This is an interesting idea. I've had a bit of a think about how such a workflow could be implemented using NCrunch, but it's difficult to find a clean way to do this using the current structure without introducing some kind of magic switch.

It seems almost to me as though you need some kind of macro. I.e. when you pin a test, it automatically switches to 'Pinned only mode', then when you unpin all tests, the mode switches back. Assuming you did all of this with shortcut keys, could you not use an AutoHotKey macro of some sort to do this for you?

I would generally recommend trying to pin tests using the keyboard shortcuts where you can. Not because of any sort of convention, but just because it's faster. We do tend to get very attached to our mouse when we write code, without really noticing how much it slows us down.

But anyway, you're right in that a magic switch is definitely not too much magic at all :) There is already a magic switch for the auto-pinning of new tests (which was added in V2). This would simply be another switch.

The big thing that I'm starting to get scared of is just how many configuration options now exist within NCrunch. The idea was to try and keep it as a simple tool to use, but it's now starting to get quite daunting. Many of the options and switches in NCrunch aren't relevant for the majority of users, and they make it difficult to identify the options that are. I guess I'm trying to prevent NCrunch from become a massive pocketknife where I would rather it was more of a targeted tool. Unless there is a wider calling for an option such as this, I may need to push such requests back until the configuration system can be simplified to make the more important options easier to manage. This will take a bit of UX work I guess.

Absolutely :) I have been looking at ways this could be done. It's all still long term thinking though. There's a few new hoops I'd like to see the engine jump through before I start fixing it down with a plugin model.

Where the 'no other tests are pinned' condition is concerned, this is a very different kind of condition as it applies to the state of the entire engine, rather than that of a single test. Such conditions could be very powerful, but are also much harder to implement with satisfactory performance. Thanks for the suggestion though - I will think about it :)