Selenium Grid

 Presentation
Selenium Grid is a solution enabling web-testing on a larger scale and continuous integration
Selenium RC gives a lot of possibilities but:

• Selenium RC struggles when running concurrent tests
• It is slow
• How would you simultaneously tests across different OS and browsers?

The architecture of Selenium Grid allows to resolve these problems:

Selenium Grid Overview

1. Test client sends commands to the Selenium Hub

2.      Selenium Hub redistributes tests on the Grid environment

• Each server can have a different environment
• You target your tests to a specific environment
2. Selenium RC servers run on servers and drives browser instances
3. Tests run in parallel against the application server

Note: While more powerful, Selenium Grid is hard to implement and maintain. Usually you’ll want to let it be managed by another tool, like Hudson for instance

 Where to start?

When you decide to use Selenium, the first approach you will have is to create tests for everything. DON’T. You will increase the size of your tests for features that will change or are not essential. Instead, just start like this:

1. Create smoke tests: basic tests that ensure that the application has the minimum level of functionality (an user can log-in, log-out…)
2. Test your "Money-path": test the functions that makes your business run: for an online store, it’s the selling process
3. Grow your test-suites organically: systematically test new features
4. Test other features only after

What Are The Issues?

Most frequent problems with Selenium

Main Problems

• Tests are brittle because:
• Written in plain old Selenese
• Developers don’t include enough ids in pages to facilitate testing, resulting in an excessive usage of XPath and DOM
• Not using page abstractions
• Most companies have their own infrastructure:
• They have to maintain it
• It involves engineering and design: it’s a project in itself
• Tests are slow because:
• They rely too much on Selenium and test every aspect of the application even if Selenium is not made for that
• Selenium should be used mostly where there is JavaScript
• Selenium in itself is mostly JavaScript running in a browser
• Extensive use of XPath, which is slower than other locators techniques (especially on IE)

You could eliminate the speed and infrastructure related problems outsourcing your Selenium setup to companies like Sauce Labs but remains the brittleness and design problems:

• Developers should facilitate QA’s work at the application level: use ids!
• Use page abstractions models like UI-element and pageObject
• Everyone should be involved in the definition of the Selenium tests' scope

Continuous Integration

• If you decide to use your own infrastructure to support Selenium
• Integrate as much as possible with a CI system
• If you are Agile, test automation is crucial and developers often write tests themselves: the limit between development and QA is thin
• These systems also offer reporting features
• Make your architecture parrallel right from the beginning: don’t wait for your tests to take an hour to start wondering how you can make it faster
• Keep in mind that when it comes to Selenium, parallelization is basically the only way you can accelerate tests
• Popular CI configurations seen in the industry:

• Hudson: Hudson is an integrated CI solution easy to deploy and use.
• A Selenium Grid plugin for hudson exists: it automatically deploys a Selenium Grid on your hudson infrastructure!
• Uses Ant but plugins exists for Rake, Ruby and Python (and many others)
• Integrates build, tests and reporting features
• An implementation example:
• 
  

1. Team checks-in their code onto a SCM
2. Hudson detects the commit and pulls the changes, compiles
3. Hudson deploys the application on a test server
4. Hudson starts the slaves and send them the tests
5. The Selenium slaves launches browsers and tests the app like Selenium RC would
6. Hudson produces reports, sends emails or IM to warn the team in case of failure
• CruiseControl: CruiseControl is an older but very popular CI system

• It supports Ant, Rake, Maven and many others via 3rd party plugins
• Implemented in Java, but Ruby and .Net versions are available (respectively CruiseControl.rb and CruiseControl.net)
• It does not provide a reporting feature, you have to do it yourself
• Example:
• 
  

1. Teams commits code on a SCM
2. CruiseControl launches the build, deploy and test
3. The Selenium tests are executed on a RC or Grid infrastructure
4. Tests runs against a browser
5. Reports are produced depending on the infrastructur