Processing Queue

The processing queue window can be accessed at any time by opening the top menu and selecting Processing Queue.

Its primary function is to give you insight into work being performed by the NCrunch engine, and as such it's a great way to check up on the engine to see how well it's dealing with your solution and how much work is still left to do.

The engine itself is capable of performing three basic tasks:

Build Assembly

This involves using MSBuild to build and compile the target assembly from a standard .proj file. Build behaviour should be almost identical to the builds handled by your IDE. In cases where differences in NCrunch's build environment cause problems, have a look at troubleshooting build issues.

Build tasks will usually take priority over Test tasks, as assemblies need to be built before the tests can be run. NCrunch will attempt to perform builds in parallel where configured to do so, and will handle them in a standard order of dependency.

Build failures will be shown in the processing queue with a red X icon.

When a build is being performed for the first time, NCrunch will take a bit longer to first create a workspace for the target project. This involves copying files to a sandbox location on the hard drive so that the build does not interfere with other processes (such as the IDE). After several workspaces have been created, the build times should drop drastically.

Builds also include instrumentation work that is used by Test tasks to trace test code coverage.

Analyse Assembly

This involves loading the assembly into an application domain and using runtime reflection to analyse it, identifying tests to be run. This step only exists if you are making use of a framework that is set to use dynamic analysis. If you have tests that are incorrectly structured or contain functional problems that can be identified before they are run, you may see errors appear from this task.

Run Tests

After a build and/or analysis has been completed, NCrunch will automatically seek out and pipeline tests into tasks for execution. Tests are grouped and prioritised by considering a range of attributes and metrics. The grouping of multiple tests per 'test run' greatly reduces system load at the expense of making it sometimes harder to identify precisely which test is executing at a given moment (i.e. a task that runs 200 tests will give no specific details on the running progress of each test).

Test tasks will always be run in parallel where configured to do so, though two tests will never run concurrently within the same process.

You can see which tests are running within a particular task by drilling down onto it within the view. You can also do this to evaluate the status of the tests (i.e. pass or fail), though for daily use the tests window is much more suitable for this.

Processing Queue Fields

It's also possible to customize the columns shown in this view to get more information about the tasks under execution. Right click the table header to open up a menu to choose which columns are visible.