The below mentioned theory explains about the setup of Selenium Grid with architecture and how it works.
Selenium Grid builds on the traditional Selenium setup, taking advantage of the following properties:
* The Selenium test, the application under test, and the remote control/browser pair do not have to be co-located. They communicate through HTTP, so they can all live on different machines.
* The Selenium tests and the web application under test are obviously specific to a particular project. Nevertheless, neither the Selenium remote control nor the browser is tied to a specific application. As a matter of fact, they provide a capacity that can easily be shared by multiple applications and multiple projects.
Consequently, if only we could build a distributed grid of Selenium Remote Controls, we could easily share it across builds, applications, projects - even potentially across organizations. Of course we would also need to address the scalability issues as described earlier when covering the traditional Selenium setup. This is why we need a component in charge of:
* Allocating a Selenium Remote Control to a specific test (transparently)
* Limiting the number of concurrent test runs on each Remote Control
* Shielding the tests from the actual grid infrastructure
Selenium Grid calls this component the Selenium Hub.
* The Hub exposes an external interface that is exactly the same as the one of a traditional Remote Control. This means that a test suite can transparently target a regular Remote Control or a Selenium Hub with no code change. It just needs to target a different IP address. This is important as it shields the tests from the grid infrastructure (which you can scale transparently). This also makes the developer’s life easier. The same test can be run locally on a developer machine, or run on a heavy duty distributed grid as part of a build – without ever changing a line of code.
* The Hub allocates Selenium Remote Controls to each test. The Hub is also in charge of routing the Selenese requests from the tests to the appropriate Remote Control as well as keeping track of testing sessions.
* When a new test starts, the Hub puts its first request on hold if there is no available Remote Control in the grid providing the appropriate capabilities. As soon as a suitable Remote Control becomes available, the Hub will serve the request. For the whole time, the tests do not have to be aware of what is happening within the grid; it is just waiting for an HTTP response to come back.
Selenium Grid builds on the traditional Selenium setup, taking advantage of the following properties:
* The Selenium test, the application under test, and the remote control/browser pair do not have to be co-located. They communicate through HTTP, so they can all live on different machines.
* The Selenium tests and the web application under test are obviously specific to a particular project. Nevertheless, neither the Selenium remote control nor the browser is tied to a specific application. As a matter of fact, they provide a capacity that can easily be shared by multiple applications and multiple projects.
Consequently, if only we could build a distributed grid of Selenium Remote Controls, we could easily share it across builds, applications, projects - even potentially across organizations. Of course we would also need to address the scalability issues as described earlier when covering the traditional Selenium setup. This is why we need a component in charge of:
* Allocating a Selenium Remote Control to a specific test (transparently)
* Limiting the number of concurrent test runs on each Remote Control
* Shielding the tests from the actual grid infrastructure
Selenium Grid calls this component the Selenium Hub.
* The Hub exposes an external interface that is exactly the same as the one of a traditional Remote Control. This means that a test suite can transparently target a regular Remote Control or a Selenium Hub with no code change. It just needs to target a different IP address. This is important as it shields the tests from the grid infrastructure (which you can scale transparently). This also makes the developer’s life easier. The same test can be run locally on a developer machine, or run on a heavy duty distributed grid as part of a build – without ever changing a line of code.
* The Hub allocates Selenium Remote Controls to each test. The Hub is also in charge of routing the Selenese requests from the tests to the appropriate Remote Control as well as keeping track of testing sessions.
* When a new test starts, the Hub puts its first request on hold if there is no available Remote Control in the grid providing the appropriate capabilities. As soon as a suitable Remote Control becomes available, the Hub will serve the request. For the whole time, the tests do not have to be aware of what is happening within the grid; it is just waiting for an HTTP response to come back.