Hi, thanks for posting.

Right now no feature exists allowing fine grained control over a test's priority in the queue, outside of pinning the test to the Tests Window.

If you haven't already, I strongly recommend marking this slow running fixture with NCrunch.Framework.AtomicAttribute, as this will prevent the engine from slicing it up across multiple runs (rare but sometimes can still happen).

It strikes me that what you may be searching for is a way to maximise throughput from the engine rather than improve response times. Is this an end-to-end console testing scenario? Other than trying to minimise your end-to-end testing times, is there any reason why you would want this test to run earlier in the batch?

Thanks for clarifying this. I can empathise with the frustration involved in waiting for test runs while doing large restructuring or merging in a codebase.

Given the current feature set, unfortunately we're limited to the following conventional options in improving this for you:
- Keep the test pinned at all times. I realise it adds clutter to the Tests Window, but the priority boost from the pinning will make a noticeable difference in priority.
- Increase the capacity of the engine as much as possible. If you're already using all available local capacity, consider setting up grid nodes to increase it further. The more task runners you have, the faster your run will complete and the earlier NCrunch will be able to pick up the big test.
- Turn off your Fast Lane threads (set them to zero). This will free up additional capacity for the big test, allowing it to be processed earlier in the run.

There is a less than conventional approach that may also help. It's possible to set up a grid node server on your local machine, then use the 'Tests to run on this computer' configuration setting on the grid node so that it will ONLY run the big slow test, ignoring everything else. By connecting your NCrunch to this local grid node, you'll have effectively reserved a processing thread for targeted execution. Note that you'll need to subtract a processing thread from the NCrunch client to make up for the extra resources being used by the background grid node.

We do have rough plans to introduce a different run mode to the engine that will make the engine favour throughput over responsiveness. The intention is for this to be used on CI servers (i.e. console tool use case), but I feel it may also work well for your scenario. As this is still in the concept stage, unfortunately I can't yet commit to the delivery of this feature with any certainty.