In this series, we are going to dive into some benefits and examples of a Test Automation Framework. A framework is an architecture of integrated parts. Some of those integrated parts are libraries, test data, and Page Object Model (POM). For Selenium, Data-Driven and Hybrid are two popular Test Automation Frameworks:
- Data-Driven Framework – read values from a test source, then store the values in a test script.
- Hybrid Framework – consists of two or more frameworks plus utilities, logs, reporting, etc.
Table of Contents – Test Automation Framework Benefits
- Benefits – Test Automation Framework
- Example – Test Automation Framework
- How To Install Selenium Drivers via TestProject’s Agent
- How To Create Development Token
- Model Your First Page Object Model (POM)
- How To Build CSS Strategy Using Chrome Developer Tools
- Create Test Class Using POM and TestProject’s OpenSDK
- View Example Report In TestProject
A Page Object Model is a design pattern with classes that represent each page of an application. It can also represent components within a page. For example, if an application has a Login Page then the Page Object may have a LoginPage class. After creating a Page Object class, each individual test script has access to the class. All test scripts are stored separately from the variables and methods. Here’s a screenshot that shows the Web Pages, Page Objects, and Test Scripts:
The benefits of a Page Object Model are code readability, code reusability, and code maintainability. Code readability means the code is descriptive and easy to follow. Code reusability is a technique for reusing the same code in multiple locations. Code maintainability is an approach of taking less time to make a change to our code.
The results from a Page Object Model greatly outweighs a plain vanilla test. A vanilla test has everything like locators in each test script. Therefore, if a change happens in the Application Under Test (AUT), then each test script requires an update to its locator. This approach defeats the benefits of a Page Object Model such as code maintainability.
It’s time-consuming to update the locator in multiple test scripts. Can you imagine how long it would take if the AUT had more than one change? 🤯 That means each test script demands multiple updates for successful execution. However, the Page Object Model only requires an update in one place ✅
The OpenSDK from TestProject is a complete coding solution for Test Automation. It’s unified across multiple programming languages: Java, C#, and Python. One of the benefits is an extension of Selenium and Appium. The standard Selenium and Appium drivers are wrapped within TestProject’s powerful Agent that takes care of all the maintenance & heavy-lifting for you, while extending Selenium and Appium with additional features, such as AI and automatic out-of-the-box reporting.
Selenium is designed for web testing while Appium is built for mobile testing. Therefore, the TestProject OpenSDK possesses the ability to test web and mobile applications. It’s comparable to getting the best of two worlds, plus additional features like API testing. A few more benefits include:
- Support for Windows, Mac, Linux, and Docker
- Support for RESTful API
- Store and execute tests locally on any source control tool like Git
- Test runner capabilities for local and remote execution
- Automatic test reports in HTML/PDF format
- Screenshots included in the test report
- Reporting dashboard with execution history
TestProject has several built-in test report dashboards (Velocity, Distribution, Platforms, Trends, Targets, Individual Run) and an API to get the report. We can manually create a test report or automate the report into our Continuous Integration (CI) pipeline. When it comes to logging, TestProject uses an SLF4J API. We can implement Log4j, Logback, or Java Logging to control the logging output. The following is a screenshot of CI/CD using TestProject OpenSDK:
The purpose of a Selenium locator is to help us find elements on a web page. An element is anything you see on the page such as buttons, text boxes, links, etc. The two most powerful Selenium locators are CSS Selector and XPath. CSS Selector finds an element by the CSS Selector’s engine. XPath finds an element by its XML Path. Both are powerful because they assist with finding all types of elements. In addition to CSS Selector and XPath, Selenium provides 6 more locators:
- className – finds an element by the value of its class attribute.
- id – finds an element by the value of its id attribute.
- linkText – finds a hyperlink element by its complete text.
- name – finds an element by the value of its name attribute.
- partialLinkText – finds a hyperlink element by partial text contained within the complete text.
- tagName – finds an element by its tag name.
With the release of Selenium 4, Relative Locators are added to the existing 6 locators to find elements based on the location of another element:
- above – finds an element or elements located above a fixed element.
- below – finds an element or elements located below a fixed element.
- near – finds an element or elements located near a fixed element.
- toLeftOf – finds an element or elements located to the left of a fixed element.
- toRightOf – finds an element or elements located to the right of a fixed element.
Although there are many Selenium locators, the benefit of using CSS Selector or XPath is their flexibility. They provide different options for finding an element. As a result, we can locate complex elements like dynamic elements. A dynamic element is an element with a continuously changing value upon reloading the web page. We can locate elements that start with a specific value, end with a specific value, contain a certain value, and many more complicated elements. The following are CSS Selector and XPath syntaxes that can also be downloaded via the below Cheat Sheet 😉
XPath • //TagName[@AttributeName='AttributeValue'] • //TagName[@AttributeName='AttributeValue'][@AttributeName='AttributeValue'] • //TagName[@AttributeName='AttributeValue' and @AttributeName='AttributeValue'] • //TagName[@AttributeName='AttributeValue' or @AttributeName='AttributeValue'] • //TagName[@AttributeName='AttributeValue']/TagName[n]/TagName[n] XPath Partial Pattern Match - //TagName[PartialPatternMatch(@AttributeName,'AttributeValue')] • //TagName[starts-with(@AttributeName,'AttributeValue')] • //TagName[contains(@AttributeName,'AttributeValue')] XPath Search For Text • //TagName[text()='Value'] XPath Axes • //TagName[text()='Value']//preceding::TagName[n] • //TagName[@AttributeName='AttributeValue']//preceding::TagName[n] • //TagName[text()='Value']//following::TagName[n] • //TagName[@AttributeName='AttributeValue']//following::TagName[n] CSS (* = any TagName / # (pound) = ID AttributeName / . (dot) = Class AttributeName) • TagName#AttributeValue • TagName.AttributeValue • TagName[AttributeName='AttributeValue'] • TagName[AttributeName='AttributeValue'][AttributeName='AttributeValue'] CSS nth-child(n) Syntax • TagName[AttributeName='AttributeValue'] TagName TagName:nth-child(n) TagName CSS Child Select (> = Parent-Child Relationship) • TagName.AttributeValue > TagName.AttributeValue • TagName.AttributeValue > TagName#AttributeValue CSS Symbols For Matching Patterns - TagName[AttributeName Symbol='AttributeValue'] • (^ (caret) = starts-with / * (asterisk) = every element with a specific substring • TagName[AttributeName^='AttributeValue'] • TagName[AttributeName*='AttributeValue']
JUnit is a Unit Testing Framework that’s part of the Test Automation Framework. The goal is to provide a way for testing our code. According to the User Guide, JUnit 5 is unlike previous versions. JUnit 5 is composed of several different modules from 3 different sub-projects. The sub-projects are JUnit Platform, JUnit Jupiter, and JUnit Vintage:
- JUnit Platform serves as a foundation for launching testing frameworks on the JVM.
- JUnit Jupiter is the combination of the new programming model and extension model for writing tests and extensions.
- JUnit Vintage provides a test engine for running JUnit 3 and JUnit 4.
Some of the benefits include code quality, debugging process, and locate defects early. Code quality impacts the overall quality of an application. Therefore, JUnit ensures the code is reliable and testable. The debugging process helps us detect and remove defects in our code. It is important because we can prevent unexpected or incorrect software operations. Last but not least, is locating defects early in the Software Development Life Cycle (SDLC). This benefit produces additional benefits such as reducing business risk, reducing cost, and improving application security. Eliminating a defect early is better than waiting for a problem to occur in production.
An example of a Test Automation Framework will be next. Stay Tuned 😊