I am using TestNG framework for selenium webdriver scripts. I run them periodically using Jenkins in slave machines. I do not use Selenium Grid. What is the advantage of using selenium grid over jenkins in running the webdriver automated testcases? Please clarify if my understanding is completely wrong.
Well Selenium Grid helps you to run your tests in parallel on multiple different nodes (slave machines) which are to be registered to central hub. You create your driver object by sending the request to the hub which finds a matching node based on the desired capability you have set, and executes the test on that node.
While Jenkins is a continuous integration tool. It cannot distribute your test cases over multiple nodes. In fact jenkins is nothing specific to selenium, it is just a CI tool. It is a triggering point of your tests after your builds.
If you need to distribute your tests across machines I think you should use Selenium Grid simply because it will do the management of distribution and do a lot of work underneath.
However, since jenkins allows you to run multiple nodes you can use it to distribute your tests but then you have to management part where you distribute your tests and then get a consolidated report. Selenium plugins might be of some help in that respect.
Jenkins has the ability (via the Selenium Plugin) to run a local standalone Selenium server. You can use multiple Jenkins slaves to parallelize testing (on a per-job basis.)
Selenium Grid allows you to separate Selenium execution from Jenkins and you can have parallel execution of tests in a single Jenkins job.
Why would you use Jenkins Selenium Plugin instead of grid?
- when you want a simple setup and don't want to manage a grid
- when you need to use a local Selenium instance instead of a grid node
- when you want to take advantage of other Jenkins features (such as tagging a build to run on a node with certain capabilities)
Some advantages of running Grid instead of the Jenkins plugin:
- you can easily specify browser capabilities
- you can have parallel tests executing on a single job
- you can more easily scale up (Jenkins is notoriously unstable with a large number of slaves)
- you can offload the heavyweight testing processes (CPU, Memory, and Network I/O) from your Jenkins slaves and run more concurrent jobs.
You can run grid with Jenkins slaves, but there is the overhead that your tests still need to wait for the Grid node to report back to the Jenkins slave that running has complete. You can't have an async job that "sleeps" until a completion notification is triggered (though, come to think of it, that might be a nice feature for Jenkins.)
But that's also the main weakness -- now you've inserted network communication as an additional variable in your jobs running Selenium tests. Not just communication with the Selenium Grid hub, but reporting back that the test is complete -- and killing off jobs that don't get that response due to a problem with your tests (like browser dying).
Selenium Grid allows for multiple runners to check in and get their code next steps or executions. Jenkins is used to build the code / call the work to be processed.
What always helped me was thinking of the manager with a clip board as the grid. Upper level management (Jenkins) tells the manager (Grid) to go run these test steps. The Manager (Grid) allocates the work to it's workers to actually get it done. everything is reported back to the Manager and ultimately back to upper level.
Well Selenium Grid helps you to run your tests in parallel on multiple different nodes (slave machines) which are to be registered to central hub. You create your driver object by sending the request to the hub which finds a matching node based on the desired capability you have set, and executes the test on that node.
While Jenkins is a continuous integration tool. It cannot distribute your test cases over multiple nodes. In fact jenkins is nothing specific to selenium, it is just a CI tool. It is a triggering point of your tests after your builds.
If you need to distribute your tests across machines I think you should use Selenium Grid simply because it will do the management of distribution and do a lot of work underneath.
However, since jenkins allows you to run multiple nodes you can use it to distribute your tests but then you have to management part where you distribute your tests and then get a consolidated report. Selenium plugins might be of some help in that respect.
So far I am using newest Jenkins and there is a possibility to add nodes there. I am wondering then is there any reason to use a Selenium Grid? I was trying to use Selenium Grid 4 (the newest one) via the jar file as hub on the same server where Jenkins is running, because the Selenium plugin for Jenkins has serious vulnerability that does not have any fix and I do not want to use it. I was not able to login to the Selenium web management console, even if the port 4444 on a firewalld is allowed. Probably will have to install the Selenium grid hub on a separate server. Anyway I do not see any logical reason to use a Selenium Grid at all, if I can add multiple nodes in Jenkins and perform the tests from Jenkins on those nodes added via ssh (Linux nodes) or directly via Java jar files (Windows nodes).
© 2022 - 2024 — McMap. All rights reserved.