Relationship between NUnit, Selenium, Selenium Grid and Specflow and the role/purpose of each

Question

After modifying the test code (C#, Selenium + Specflow VS 2017 project) to run with selenium grid and setting up the selenium server on my machine the tests successfully ran in parallel.

I was confused to see the test still run in parallel when I shut down the selenium server and modified the test code back to just use the webDriver instead of the RemoteWebDriver ... However, I had not removed the following line of code from the AssemblyInfo.cs file:

[assembly: Parallelizable(ParallelScope.Fixtures)]

The test ran serially again once the above line of code was commented out.

Question-1: Is this correct that both Selenium and Specflow have their own tools (not just selenium) to allow test to run in parallel? This is the conclusion after spending time reading trying to figure out why/how this magic was happening (specflow parallel). Until this unexpected behavior, I had not read anything about specflow parallel tools (just always selenium grid).

Question-2: Which is best to use? I am guessing that although running parallel with Selenium server parallel tools (Selenium Grid) is more involved, Selenium Grid might be best in the long run. Looks like with Selenium Grid, you can probably run a ton more threads at once since you can create as many nodes as you like and each node can handle several threads (browsers).

---

Edits after JimEvans Comments:

Hi Jim Evan. I've come across your name a lot when reading info in the testing world. Thanks so much for the info. Your statement below redirected my reading and search for info. After reading up more on what you've said, this is what I now understand. I was wondering how close this was to being correct ... especially statement #4.

1. The statement [assembly: ... ] within the AssemblyInfo.cs is read and understood by the NUnit testing framework. If NUnit didn't exist the statement [assembly: ...] would not exist.
2. Both Specflow and Selenium can be laid on top of (work with) different testing framework's; one of them being NUnit. Both Specflow and Selenium work to make sure their libraries (code on top of NUnit) does not block the use of the NUnits parallel capabilities.
3. It appears that specflow might have placed some restrictions on threading. It looks like the Specflow architecture might be best suited to run features (fixtures ... ParallelScope.Fixtures) in parallel but doesn't allow scenarios within a feature to run in parallel (ParallelScope.All might not work in Specflow but need to look into this more).
4. Is this a correct statement: Selenium Grid takes NUnit parallel execution to the next level ... it makes it even more powerful by allowing tests to run on several nodes ... the nodes either being on 1 machine or spaced out across several machines (access to more processing power). I am guessing that without Selenium Grid, NUnit could only create so many threads due to hardware limitations. Selenium Grid acts as a sort of manager of available space (most of the time across several machines) for running tests. The Selenium webdriver is closely tied to the browser and browser interaction (opening and closing of the browser); one browser per thread; NUnit is in control of and manages the threading; Selenium Grid knows how many resources (processors and machines) are available for running the threads on which allows NUnit to keep spinning out new threads and selenium webdriver can then open a web browser on that thread and start testing.

I started to interpret the info in the image below differently after understanding that Selenium has no special code to execute in parallel (it's a good statement describing Selenium Grid).

Location the above text came from

Answer 1

SpecFlow is a Behavior Driven Development test framework for C#

SpecFlow does work with a wide variety of test runners - In your case Nunit is acting as the runner. [Nunit can be used as a framework without specflow as well]

The statement [assembly: ... ] within the AssemblyInfo.cs is read and understood by the NUnit testing framework. If NUnit didn't exist the statement [assembly: ...] would not exist.

-- Correct . [assembly: Parallelizable(ParallelScope.Fixtures)] [Parallelizable attribute is from Nunit ]1

Both Specflow and Selenium can be laid on top of (work with) different testing framework's; one of them being NUnit. Both Specflow and Selenium work to make sure their libraries (code on top of NUnit) does not block the use of the NUnits parallel capabilities.

-- SpecFlow is a Behavior Driven Development test framework for C# and Nunit is acting as the runner.There are other runner as well e.g. xUnit,MsTest V2 . Specflow is using the Nunit to run the features in parallel. Think of Selenium as separate library which has nothing to do with parallel execution.

It appears that specflow might have placed some restrictions on threading. It looks like the Specflow architecture might be best suited to run features (fixtures ... ParallelScope.Fixtures) in parallel but doesn't allow scenarios within a feature to run in parallel (ParallelScope.All might not work in Specflow but need to look into this more).

-- Specflow+NUnit runs features in parallel if you add Parallelizable(ParallelScope.Fixtures) in Assembly .

Refer : Specflow+NUnit just run features in parallel not scenarios

Is this a correct statement: Selenium Grid takes NUnit parallel execution to the next level ... it makes it even more powerful by allowing tests to run on several nodes ... the nodes either being on 1 machine or spaced out across several machines (access to more processing power). I am guessing that without Selenium Grid, NUnit could only create so many threads due to hardware limitations. Selenium Grid acts as a sort of manager of available space (most of the time across several machines) for running tests. The Selenium webdriver is closely tied to the browser and browser interaction (opening and closing of the browser); one browser per thread; NUnit is in control of and manages the threading; Selenium Grid knows how many resources (processors and machines) are available for running the threads on which allows NUnit to keep spinning out new threads and selenium webdriver can then open a web browser on that thread and start testing.

Lets say we have two feature files. Feature File 1 - Scenario A Feature File 2 - Scenario B

Assuming we are creating one instance of the Chromedriver in one Feature (one thread).

If two features are running in parallel then we have two chromedriver instances . When we create instance of chromedriver (remote) then request will go to Selenium Grid hub. As per capabilities Selenium Hub will forward the request to capable node. Node will create the session(browser) and send session id back to client (Here its C# Selenium). All future communication will happen using this unique session id. As we are running two features in parallel we will have two session ids. One session id for one thread.

For running the scenarios in parallel on local machine you may not need the Grid (RemoteWebDriver) that you have already figured out as mentioned in question.

Selenium hub does not have information about the processor /machine. Hub just know about the registered nodes.

Above information is in context of Selenium Grid 3

You may want to learn about Selenium Grid 4 Selenium Grid 4 There three ways to run the new Grid

1. "standalone"
2. "hub" and "node"
3. "router","distributor", "sessions", and "node"