Selenium Grid VS Jenkins

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.