3pillarlabs/qa-automation-starter-sdk

Name: qa-automation-starter-sdk

Owner: 3Pillar Global Open Source

Owner: 3Pillar Global Open Source

Description: QA automation framework for browser, APIs and mobile apps. Easy to set up, simple to use and extend.

Created: 2018-02-08 17:10:37.0

Updated: 2018-03-16 02:19:53.0

Pushed: 2018-03-29 11:14:03.0

Homepage:

Size: 5416

Language: Java

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

QA Automation Starter SDK

This SDK provides common libraries and utilities for a test automation framework across web, APIs and mobile. There are two ways to use this SDK:

• Clone the SDK and add application specific test data, tests and page objects.
• Clone the SDK and set it up as a dependency for an application specific test automation framework.

Highlights

• Element Hierarchy - A hierarchy of elements with standard behavior for each element.
• No Waits - Ability to write operations in the page object methods assuming total synchronous behavior. All waits are handled by the framework.
• Listeners - A collection of most useful listeners such as a listener to integrate test execution with TestRails.
• Reports - Ability to customise reports.
• Spring Boot - the test automation framework works as a Spring Boot application.
• Depedency Injection - the framework uses Spring to instantiate test classes and inject dependencies.
• Test Data Framework - framework that provides test data stored in JSON files. Modeled on Fixjures and Fixture-Factory

Technology Stack

• Java 8
• TestNG
• Selenium Webdriver
• RestAssured
• Appium
• Logging - slf4j, logback
• Gradle

CI/CD

• Build Status - TravisCI
• Code Quality - CodeClimate

Structure

The SDK is a multi-module Java application.

d.gradle
ings.gradle
on/
c/
main/java
test/java

c/
main/java
test/java

c/
main/java
test/java
le/
c/
main/java
test/java
sample-app/
c/
main/java
test/java
sample-app/
c/
main/java
test/java
le-sample-app/
c/
test/java

Writing Tests

This is just an initial idea. In the actual implementation the test class may extend an abstract class or adhere to an interface.

ogin Tests

ic class LoginTest {

 inject page object
nject
ivate LoginPage loginPage;

est(dataProvider = "validUsers")
blic void successfulLogin(Set<User> users) {
for (User user : users) {
  loginPage.login(user);
}




age object for Login page

lic class LoginPage {

/ inject the WebDriver instance
Inject
rivate WebDriver webDriver;

/ inject other Page Objects
Inject
rivate DashboardPage dashboard;

/ declare the fields
PageElement(tag = By.ByName, value = "login.UserName")
rivate TextField userName;

PageElement(tag = By.ByName, value = "login.Password")
rivate TextField password;

PageElement(tag = By.ByTagName, value = "button")
rivate Button submit;

ublic DashboardPage login(User user) {
 try {
   userName.setText(user.getUserName());
   password.setText(user.getPassword());
   submit.click();
   return dashboard;
 } catch (WebException e) {
   logger.error(e.message, e);
   return this;
 }




Data provider

ic class UserDataProvider {

ataProvider(name = "validUsers")
blic static Object[][] validUsers() {
// Use the Data framework to fetch valid users