UI Test Automation Design
Auto tests design problems
Your success in test automation depends not only on selected tools but also on how you design your tests.
First, consider an example of typical test automation that does not use any abstraction. This is a simple login scenario automated using Selenium WebDriver and written in Ruby:
There are several problems with this approach:
- No separation between the test method and control locators
- Locators would be spread in multiple tests
- If developers make any small UI changes it would be difficult to update your tests
So our goals are:
- Reduce code duplication
- Enhance test maintenance
Page Object Design Pattern
One of the solutions is to use Page Object Model. Page Object is a Design Pattern, which has become popular in test automation for enhancing test maintenance and reducing code duplication. A page object is an object-oriented class and contains the representation of the page with the services the page provides via methods. The tests then use the methods of this page object class whenever they need to interact with that page. The benefit is that if the UI changes for the page, the tests themselves don't need to change; only the code within the page object needs to change. Subsequently all changes to support that new UI are located in one place.
The Page Object design pattern provides the following advantages.
- There is clean separation between test code and page specific code such as control locators and layout.
- There is a single repository for the services and operations offered by the page rather than having these services scattered throughout the tests.
In both cases this allows any modifications required due to UI changes to all be made in one place.
How to implement your Page Object Model
- For each web page you have a Page class. All control locators and methods for that page should be put in this class.
- All test logic and verifications should be put in test classes.
- All shared controls or methods should be put in a base page class.
- A Page class does not necessarily need to represent an entire page. It could be used to represent components on a page like frames.
Creating Login page class with page-object gem
To create the Login page class for our scenario above we will use Page Object gem (see more info here https://github.com/cheezy/page-object)
Usage of the page would be:
Creating your page object
Page-object gem supports both watir-webdriver and selenium-webdriver. The one used will be determined by the driver you pass into the constructor of your page object. The page object can be created like this:
or
Test Data Design
Another problem that projects may face is long test execution time due to an increasing number of tests. The solution is to run tests in parallel, which is only possible if test data is designed properly. Ideally your tests should not depend on other tests data or change the data of other tests. Finally, tests should run on all environments: local, CI and deployed environments such as production.
Tools
For UI test automation in Simulmedia we use the following tools:
- Cucumber - to write acceptance tests in BDD style
- To automate tests we used Selenium WebDriver and started using Watir WebDriver + Page Object gem for new projects.
- We use Ruby language and our developers use it too.
- For verification steps we Rspec-expectations
- For continuous integration we use Jenkins build server and we are running our tests headless on Chrome and Firefox there by using Headless gem.
- We use Docker for multicomponent projects
If you want to start your automation process by using Ruby language + Cucumber + Watir WebDriver + Page Object gem check out the following book from Jeff Morgan: Cucumber and Cheese