0

We updated our solution from SpecFlow1.9 to 2.0 and NUnit2.6.4 to 3.2.1. After adapting some attributes and project settings, all tests run fine in NUnit. However, when the SpecFlow tests are executed with NCrunch, we get a SpecFlowException:

TechTalk.SpecFlow.SpecFlowException : The ScenarioContext.Current static accessor cannot
 be used in multi-threaded execution. Try injecting the scenario context to the binding
 class. See http://go.specflow.org/doc-multithreaded for details.
 at TechTalk.SpecFlow.ScenarioContext.get_Current()

We intentionally designed our SpecFlow tests for a single-threaded environment (to keep the effort low) and we just want to continue executing these tests in one thread. So instead of injecting the scenario context as the proposed solution (we use NInject instead of the SpecFlow mini-IoC) we're looking for some setting to convince SpecFlow that it is running in a single-threaded environment.

Here are the NCrunch 2.23.0.2 settings:

I entered in the Assembly.cs files of all SpecFlow tests the following attribute:

[assembly: Parallelizable(ParallelScope.None)]

Without success; the exception keeps showing up.

Does anybody have a clue how to force SpecFlow2.0 in NCrunch2.23.0.2 with NUnit3.2.1 so that it thinks it's executing in a single-threaded environment?

Thank you for your effort!

2016-5-31: update

I installed the new version 2.1 of SpecFlow (available since 2016-5-25) but it didn't solve the problem.

I created an example project with a minimum amount of code to generate the problem. The calculator implementation is statefull and cannot be tested in a multithreaded environment.

SpecFlow throws the exception due to the (dummy) static reference ‘ScenarioContext.Current’ in CustomContext. Yes I know you should inject it if you intend to run in a multithreaded test environment. The problem is that SpecFlow THINKS it is in a multithreaded environment, but it isn’t and it shouldn't.

Erik Stroeken
  • 519
  • 4
  • 16
  • remco has [raised an issue](https://github.com/techtalk/SpecFlow/issues/638) at the specflow issues page on github. Please follow this issue – Sam Holder Jun 01 '16 at 19:20
  • 2016-08-01 As per the issue page, this has been fixed in the pre-release version available from AppVeyor – stevef4000 Aug 01 '16 at 08:56

2 Answers2

2

On investigation, this appears to be a 3-way compatibility problem between NCrunch, SpecFlow, and NUnit3.

As part of its behaviour, NCrunch will re-use test processes by calling into them multiple times (i.e. once for each batch of tests in the Processing Queue). Because NUnit3 kicks off a new thread for each test session, it ends up using a different thread for each call into SpecFlow.

SpecFlow identifies multi-threaded execution by tracking thread IDs, and since each session has a new thread, it incorrectly thinks the code is being run in parallel when actually it's just different threads being used synchronously.

Setting the 'Test process memory limit' global NCrunch configuration setting to '1' will allow you to work around the problem, as this will cause NCrunch to throw away a test process after each batch, rather than re-using it. Unfortunately, this will have a significant impact on performance.

I've reported this problem to SpecFlow. Because of it's nature, the most sensible thing would be for it to be fixed in SpecFlow itself - https://github.com/techtalk/SpecFlow/issues/638

Remco Mulder
  • 181
  • 2
0

You need to regenerate the code-behind- files of the Feature files after upgrade.

See the upgrade steps here: http://gasparnagy.com/2016/01/specflow-tips-how-to-upgrade-your-project-to-specflow-v2/

Andreas Willich
  • 5,665
  • 3
  • 15
  • 22
  • Thanks Andreas. Already did that. All generated SpecFlow codebehind files contain 'SpecFlow Version:2.0.0.0' and as mentioned, the tests run with nunit VS plugin and nunit-console.exe, however not with NCrunch. – Erik Stroeken May 30 '16 at 10:54