Selenium Architecture

I think we're all familiar with the architecture of Selenium, right?

I mean, it's basically you talking to your browser, your test communicates directly with the browser, that's all there is to it, isn't it? What actually happens is your test talks to a driver executable, maybe Gecko driver, maybe Chrome driver, maybe Safari driver, and that talks to the browser.

That means that Selenium only need to speak the w3c WebDriver protocol and not the specific protocols each of the browsers understands. Of course, it doesn't end there, does it? Sometimes we want to be able to run our test remotely, maybe we're developing on a Mac, but we'd like to be able to run our test on windows machine so we can make use of the Selenium server.

This runs on the remote machine, connects to the driver executable, and that drives the browser. Great. We're done, right?

Well, not really, one of the things we want to do is to parallelize our test so we can run more at the same time that will not fit on a single machine. To do this, we can use Selenium grid or a Selenium as a service provider to provide that capability.