Selenium Grid VS Jenkins

KitKarson picture KitKarson · Dec 19, 2014 · Viewed 10.7k times · Source

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.

Answer

fijiaaron picture fijiaaron · Sep 17, 2015

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).