Common design principles and design patterns in automation testing

TechCon 2017

Khanh Le

Common Design Principles andDesign Patterns in Automation Testing

Introduction

Common

Design Principles

SOLID

DRY

Common

Design Pattern

POM

Fluent Page

ENDING

Agenda

Summary

Q&A

Introduction

About Me

3+ years of experience

in telecom and network.


in software testing

(manual, automation,

performance).


in company technical

Supporting Solutions,

Training and R&D.

2+ year of experience in

web security testing and

DevOps.

Common

Design Principles

O

L

S

I

Single responsibility principle

Open/closed principle

Liskov substitution principle

Interface segregation principle

SOLID PRINCIPLES

DDependency inversion principle

Every module or class should have responsibility over a single part of

the functionality provided by the software, and that responsibility should

be entirely encapsulated by the class

Single Responsibility

Everything in the class should

be related to single purpose

Single Responsibility

Should break them

into separate

classes base on

intended function.

With simplicity, it

will increase

readability,

understandability,

changeability and

maintainability

Dependency Inversion Principle

High-level modules should not

depend on low-level modules.

Both should depend on

abstractions.

Abstractions should not

depend on details. Details

should depend on

abstractions.

Copy

Read from

KeyboardPrinter

HLM: High Level Module

LLM: Low Level Module

How to write a program can read keyboard and then print this?


Copy

Read from

KeyboardPrinter

HLM

LLMWrite to

DataBase


Must modify Copy Class to interact with “Write to Database” Class


Copy

Read from

Keyboard

Include interfaces in High level module

Low level modules will implement these interfaces

Reader

InterfaceWriter

Interface

Read from

ScannerPrinter

Write to

DataBaseLLM

HLM


Apply this principle

DRY PRINCIPLE

Don't Repeat Yourself

"Don't write the same code repeatedly"

Duplicated steps in test case

DRY PRINCIPLE

Duplicated steps in test case

Common

Design Patterns

POM PATTERNA design pattern to create Object Repository for web UI elements.

There should be corresponding Page class for each web page in the application.

This Page class will find the WebElements of that web page and also contains

Page methods which perform operations on those WebElements

Operations and flows in

the UI should be

separated from

verification => our code

cleaner and easy to

understand

Code becomes less and optimized

because of the reusable page

methods in the POM classes. Methods get more realistic

names which can be easily

mapped with the operation

happening in UI

POM PATTERN

Web PagePage

Class

Base

Page

Class

Test Report

POM PATTERN

Main TC

Sub TC

Pre-

condition

Sub TC

Step

Sub TC

Post-

condition

Page

Object

API

Data

base

Base Page

Page

Functions

Page

Validations

Business flow –

Pre and PostMain business flow

POM PATTERN

Source: twitter.com

POM PATTERN

POM PATTERN

With Page factory

POM PATTERNPOM in Katalon – Solution 1

POM PATTERN

In business layer :

POM in Katalon – Solution 1


In business layer :

Fluent Page Pattern

POM +Fluent Interface

Fluent Page Pattern is POM with Fluent Interface.

A fluent interface is typically implemented by

using method cascading (concretely method chaining) to

relay the instruction context of a subsequent call.

Fluent Page Pattern


Fluent Page Pattern


Apply this pattern

Summary

REFERENCES

• http://www.oodesign.com/

• https://www.wikipedia.org/

• https://automatetheplanet.com

http://www.oodesign.com/

https://www.wikipedia.org/

https://automatetheplanet.com/

THANK YOU

Q & A

OPEN/CLOSED PRINCIPLE

”Software entities (classes, modules, functions, etc.) should be open for

extension, but closed for modification”.

Class should allow creation of new properties or methods.

Class should not allow modification of current properties or methods.

Source: wiki


Execute “Main.java”:

We want to connect with Oracle Server, what will we do?


Execute “Main.java”:


We will change the ConnectionManager Class when adding new

Database Connection

LISKOV SUBSTITUTION PRINCIPLE

“Objects in a program should be replaceable with instances of their subtypes

without altering the correctness of that program.”

Source: wiki


Replace Rectangle object to Square object for returning, the issue will come

INTERFACE SEGREGATION PRINCIPLE

“Many client-specific interfaces are better than one general-purpose interface.”

”No client should be forced to depend on methods it does not use.”

ISP splits interfaces that are very large into smaller and more specific ones.

Source: wiki


When Animal interface has

more methods, all classes must

implement these methods even

if they don’t use.

Common design principles and design patterns in automation testing

Technology

Transcript of Common design principles and design patterns in automation testing