Hi,

I'd like to try and understand some strange behaviour we see occasionally. We are running some UI tests that take a while (some minutes each) and have 5 nodes in the pool of available grid nodes. In this one test case there were 6 tests, but despite all nodes doing nothing, the distribution was 1/1/4 on the nodes, obviously meaning that the tests took a lot longer then they might have.

there is an image of the NCrunch timeline here: https://drive.google.com...BbAk7V59ZFbaffuJpPBkklP

Is there a reason this happens? is there anything we can do to make the tests be more evenly distributed?

Thanks

Sam

Thanks for posting. Looking at the timeline report, my best guess is that this is being caused by the batching of tests. In this instance, we have 5 nodes but only 3 test tasks, so two nodes are left without a task.

Do these tests have any long running code in a fixture setup routine, or are they making use of AtomicAttribute? Which test framework are you using? We need to identify why the engine is choosing to group these long running tests together in the same task.

The key variable here is the time the overall fixture takes to run excluding the time spent executing each child test. If the execution time of the fixture is too high, all of its child tests will be grouped together in the same test execution task so that the runner doesn't need to make the expensive fixture setup/teardown code run multiple times during a test run.

You can view the execution time of the fixture in the tests window. You might need to turn on the right column to see this separate from the 'total' fixture execution time.

It's possible to force the tests to run in separate tasks by adorning them with NCrunch's attributes, such as 'InclusivelyUsesAttribute'. If you tell the engine that each test makes inclusive use of a different resource, the engine will place each test in a separate task. Note this means that the fixture setup/teardown code will need to run multiple times. In this situation, the tests will be spread much more efficiently through the nodes, but the overall CPU required to run the test suite will likely be quite a bit higher.