Hi Sheryl, great to hear from you again!



As NCrunch itself only launches the execution of your tests, it doesn't have any features targeted towards tracking or managing UI tests, which are being handled by your choice of 3rd party utility (i.e. Selenium?). My suggestion would be to try setting up the grid node using the grid node console tool instead (NCrunch.GridNode.Console.exe, installed next to the main service .exe). This will let you run the grid node as the local user on the server, and thus any tests it runs will be able to interact with the desktop. You could then watch the tests run using an RDP or terminal services session.



Perhaps, in a limited way. Turning off parallel execution will stop the node from running multiple sets of tests concurrently, but it won't stop it from running builds concurrently. If you turn down the max processing threads to 1, then the grid node will only be able to pick up one task at a time (including build tasks). This will reduce concurrency and resource consumption. If the node is working slowly because of lack of resources, this may make a difference and it is worth trying.



Setting the max processing threads to 1 will make any concurrent use of resources on the grid node through NCrunch's management impossible. It is not impossible that a test could kick off a background process outside of NCrunch's management that still concurrently accesses files on the machine, but this would essentially be a malfunctioning test that would probably also create other problems on the machine.

Alternatively, making sure that all tests are using 'ExclusivelyUsesAttribute' on a specific resource will also prevent this, but if you're looking for a blanket solution for the entire codebase, changing the max number of processing threads is probably easier.



It's possible this could be happening because of the behaviour of your tests. It may well be that there is critical code running in your test run AFTER the test run has actually completed. For example, there could be some test code or code under test that is kicking off a background thread/process to perform a cleanup operation. While the cleanup operation is starting up, the test itself completes its execution. Because NCrunch thinks the test run has finished, it then terminates the process before the cleanup can finish. If the cleanup is required to realign or set up the environment for later test runs, the environment could be left in a mess. See http://www.ncrunch.net/documentation/considerations-and-constraints_multi-threaded-tests for more information. If this is indeed happening in your test suite, you'll want to fix this as it may give you inconsistent results from your test runs.



I'm not completely sure if I understand the scope of this question, so I'll try to answer it with some general theory :)

Broadly there are two forms of concurrency control:

1. Local: Test concurrency is constrained within the scope of a single machine. For example, a machine may only be able to execute a single test instance at a time, but the test may still be run on other machines at the same time. This means that if you have a resource (i.e. file, database) that exists uniquely on each individual machine, it will not be used concurrently. If the resource happens to be on a single machine and it is shared between other machines (i.e. central database), then it WILL be used concurrently. NCrunch supports this concurrency control through ExclusivelyUsesAttribute, InclusivelyUsesAttribute and SerialAttribute.

2. Distributed: Test concurrency is constrained within the scope of an entire grid. If one machine in the grid is executing the test, then no other machine in the grid is allowed to execute the test. This requires a distributed mutex to operate, which would likely need to be implemented using a central controller node that can coordinate access to the mutex across all nodes and clients. This is a large area of development that hasn't been implemented in NCrunch yet, though we may well go there in future.

IsolatedAttribute is not related to concurrency control, but rather it isolates tests to run in their own specially spawned process - http://www.ncrunch.net/documentation/reference_runtime-framework_isolated-attribute.


[/quote]

The grid nodes themselves store their configuration in the registry under "HKEY_LOCAL_MACHINE\SOFTWARE\Remco Software\NCrunch Grid Node". There are many tools available that can be used to modify the registry through the command line. The service will need to be restarted before any changes take effect.