Following the popularity of my last post regarding a Test Automation framework for Appium (Java) centered testing, I have had many requests to create one that is more centred around Selenium & C#.
As with my previous blog, 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):
Below is a proposed high-level structure for test automation projects. Each blue box represents a collection of classes or feature files:
These represent the User Stories/Acceptance Criteria (similar to 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.
Common Step Definitions file:
Create a Common Step Definitions file which can be used for step definitions used across different Feature files.
This file can also be used to construct the DriverFacade class and create the initial page object (e.g. for the HomePage). It can also quit the DriverFacade class at the end of tests. This means DriverFacade only needs to be exposed on this one Step Definition file, remaining hidden & passed between the Page Objects on all other Step Definition files (reducing the likelihood of its misuse).
Here is an example implementation (where we have refactored some of the previous steps into this commons steps file):
These are used to persist data across Step Definitions as a Cucumber scenario runs.
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 section (e.g. navigation menu) of the Website. The methods on these classes will drive the Web pages (e.g. Actions like: loginWithAValidUser()) or return information about the state of the website (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:
Future additions to this process: