Hi, thanks for posting.

To avoid confusion and to facilitate better control over system resources, NCrunch deactivates xunit's parallel execution and overrides it with its own.

NCrunch already performs parallel execution with better separation between the tests (at process level) as part of its own engine, so the advantages of using xunit's lower level parallelization are limited. So you should experience no parallel execution by xunit within the same NCrunch test runner process.

Sorry - I understand now. You're expecting that NCrunch will make use of the concurrency metadata provided by XUnit.

I'm not entirely sure if such metadata could be cleanly applied to NCrunch's concurrency rules. XUnit parallel execution is multi-threaded in-proc, which means that tests (and the code executed by them) must support multithreaded execution. This same constraint doesn't apply to NCrunch, as NCrunch's parallel execution is multi-process single-threaded. To apply XUnit's concurrency constraints into NCrunch's execution environment would result in many tests being constrained from parallel execution when they could actually be safely run in parallel using multi-process execution.

From what you've described, I suppose this may not be the case for you if your big constraint is out-of-process resources (like a database). So perhaps a configuration switch would make sense as a feature request if you like.

That's correct. It's a common misconception - http://www.ncrunch.net/documentation/concepts_parallel-execution.

Reliable parallel execution through any other method is impossible without requiring people to re-engineer their tests. Unfortunately, most people don't write tests with the intention that they can be executed with multiple threads inside the same process. If parallel execution is of no benefit and not worth the overhead, you can simply switch it off with a solution-level config setting.



You're welcome to (- BROKEN LINK -)request it as a feature[/url] if you like.