Having done both Development & Test Automation for over 10 years now, I realised the focus of this blog has been primarily on development. Therefore, I thought it would be interesting to cover some Test Automation.
Gherkin (the human readable coding language used by Cucumber) is becoming increasingly popular as more companies embrace Behaviour Driven Development (BDD). The Page Object Model is an equally important tool in the test automator's arsenal and so I was keen to show how these two structures can work together to provide a well structured, modular & easily updatable test automation framework. Please do leave any comments below, since I plan to update this framework approach as suggestions come in.
In summary, the purpose of this post is to provide an evolving best practice guidelines for structuring & writing automation frameworks, using Behaviour Driven Development (through cucumber) and good code structure (through Page Object Model pattern).
These represent the business requirements and are written in ‘business speak’ using Gherkin syntax
Step definitions are the interface between the ‘business speak’ gherkin and the technically coded Page Objects. They are made up of methods which are called when the higher level Cucumber scenarios are run.
These are used to persist data across Gherkin test steps as a Cucumber scenario runs. The data will be wiped at the end of each scenario. Rather than creating new instances of pages manually at the start of each step definition method, this way means you don't have to expose the Driver instance on every Step definition page (meaning lazy use of e.g. driver.FindElementBy().Click() at the step definition level is not possible)
TEST DATA OBJECTS:
These objects are used to store logical groupings of test data information, for example a Test User with an email and password property. They allow your test suite to pass around representations of real world objects as single entities, rather than as lots of individual variables (which can get confusing & cumbersome to maintain).
user1.password = “invalid_password”;
A separate class is created for each page or navigation menu of the Application Under Test (AUT). The methods on these classes will drive the AUT pages (e.g. Actions like: loginWithAValidUser) or return information about the state of the app (e.g.Queries like: getUsernameDisplayed).
This is simply a wrapper class between our test automation code and the third party test automation framework (e.g. Selenium WebDriver).
Below is an example of a folder structure you could use for implementing the aforementioned process:
This folder can contain Test Data Objects and any other object representations you may need for your test suite.
A façade class is one that provides a simplified gateway to more complex classes. AppDriver is one example of a façade but others can be stored in this folder.
The Utilities folder will contain classes that use static methods to provide time saving actions, such as logging.
The remaining folder titles, in the screenshot above, have been covered earlier in this document.
ADDITIONS YOU COULD MAKE: