Hi James,

Thanks for posting! This is a very common situation with most testing suites. It's often difficult to solve this outright but it can be mitigated.

Increasing your Max test runners to pool setting is a good idea, as this will reduce the chance that NCrunch will need to terminate and recycle test processes during a run, which should allow the static state to carry on to the next batch. The root of your problem is probably less to do with the batching and more to do with test processes being recycled (thus the static state gets cleared).

If you're running under NUnit, you can use a SetUpFixture to execute the code before NCrunch starts tracking test times. Note that code executed in a SetUpFixture doesn't have code coverage tracking and can be a bit harder to troubleshoot if it goes wrong, so it's generally worth making sure the code is quite reliable when you do this. Other test frameworks do also have similar constructions that you can use and will behave in the same way.

It's possible to use NCrunch.Framework.AtomicAttribute to force tests to run in the same batch, if they're making up the same fixture. NCrunch.Framework.ExclusivelyUsesAttribute can also discourage parallelisation of specific tests and fixtures which can reduce the amount of splitting between batches and cause more test runner processes to be re-used.

We have some pretty serious limitations in how smart we can make the batching as if it takes too long to build the pipeline, the performance benefits of parallel execution are negated.