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): HIGH-LEVEL STRUCTURE: Below is a proposed high-level structure for test automation projects. Each blue box represents a collection of classes or feature files:
Feature files: These represent the User Stories/Acceptance Criteria (similar to business requirements) and are written in ‘business speak’ using Gherkin syntax. Best Practice:
Step definitions: 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. Best Practice:
Code Reuse:
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): Object Buckets: These are used to persist data across Step Definitions as a Cucumber scenario runs. Best Practice:
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). Best Practice:
user1.password = “invalid_password”; loginPage.loginWithValidUser(user1);
Page Objects: 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()). Best Practice:
DriverFacade: This is simply a wrapper class between our test automation code and the third party test automation framework (e.g. Selenium WebDriver). Best Practice:
Folder Structure: Below is an example of a folder structure you could use for implementing the aforementioned process: Future additions to this process:
3 Comments
|
AuthorSeligman Ventures Ltd provide Software Testing & Development Services Archives
March 2018
Categories |