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.

I both agree and disagree with the logic here at the same time.
I understand there is no perfect solution, and I don't expect any fix, but I want to share a usecase.

Let's assume this case


Regardless if my tests run in NCrunch or any other test runner, I want no parallel execution of these tests because they are using one more more non unique files.
Even if NCrunch runs these in separate processes it still causes conflicts, even worse since it is separate processes there is no way to control locking.

I'm sure there is great NCrunch solutions for this, but I might be the only one in the team using NCrunch.
I also want the CI on the build server that runs jobs in parallel to behave the same, having tests randomly fail in NCrunch and add a fix for that and then fail on the build server is not great.
Also others on the team might fix other issues and they will still be failing in NCrunch.

Again, I don't expect a fix for this, just wanted to share what I just came across.