Development principles in test automation!

David Baak david.baak@polteq.com

2© 2016

TEST AUTOMATION==

SOFTWARE DEVELOPMENT

3© 2016

TestAbstraction

SystemUnderTest

Test(s)

4© 2016

What is clean code?

• Readable and maintainable– Straightforward– Clear intent– Logical abstractions– No surprises– Relevant in context

• Minimal – Does one thing – Is easily extensible

5© 2016

How does clean code aid test automation?

Smelly code

private String szName;

public void setValueBetweenOneAndThree(int

u32Value) {

if(!(u32Value >= 1 && u32Value <= 3)) return;

HashMap<Integer, String> kv = new

HashMap<Integer, String>();

kv.put(0, “RED”);

kv.put(1, “GREEN”);

kv.put(2, “BLUE”);

szName = kv.get(u32Value - 1);

}

Clean code

private Color color;

public enum Color {RED,GREEN,BLUE};

public void setColor(Color color) {

this.color = color;

}

Clear intent

Extensible

Single responsibility

6© 2016

Clean code - Naming

• Names should be self-explanatory

• Names should not carry redundant information or expose excessive implementation

• Names should be pronounceable

• Naming should be relevant to the problem domain

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

7© 2015

Clean code – Naming examples

waitForIt()

findCustomerOrThrowExceptionIfNotFound(String s)

int qty_pass_s

Seller

waitForAlert()

int passedScenarios

findCustomer(String customerName)

Publisher

Reseller

8© 2016

Clean code - SOLID

Single responsibilityEvery 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.

9© 2016

Clean code - SOLID

Single responsibility

An artifact should only have one reason to change

Two reasons to change

10© 2016

Clean code - SOLID

Open closedUse inheritance of abstract base classes or composition to reference other classes. Interface is then closed to modification, but the implementation can differ.

11© 2016

Clean code - SOLID

• Single responsibility• Open-closed

Code should be open to extension, but closed to modification

Modification if we introduce Square

12© 2016

Clean code - SOLID

Liskov substitutionFunctions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

13© 2016

Clean code - SOLID

• Single responsibility• Open-closed

• Liskov substitution

All the subtypes of a base type must be able to replace this base type

Rectangle r = new Square();r.setHeight(5);r.setWidth(10);Invalid area!

14© 2016

Clean code - SOLID

Interface segrationSplit interfaces which are very large into smaller and more specific ones, so that clients will only have to know about the methods that are of interest to them.

15© 2016

Clean code - SOLID

• Single responsibility• Open-closed• Liskov substitution• Interface segregation

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

Not every printer can email

or scan

16© 2016

Clean code - SOLID

Dependency inversionA specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details.

17© 2016

Clean code - SOLID

• Single responsibility• Open-closed• Liskov substitution• Interface segregation• Dependency inversion

High-level modules should not depend on low-level modules.Abstractions should not depend upon details.

Should not dependon concrete class

18© 2016

Refactoring

“Code refactoring is the process of restructuring existing

computer code – changing the factoring – without changing itsexternal behavior. Refactoring improves nonfunctional

attributes of the software. Advantages include improved code

readability and reduced complexity; these can improve

source code maintainability and create a more expressiveinternal architecture or object model to improve extensibility.”

(source: https://en.wikipedia.org/wiki/Code_refactoring)

19© 2016

Refactoring - Automation code example

Original

String bookName = "The Hobbit";

WebElement bookTableRow = driver.findElement

(By.xpath("//tbody[@class='grid']/tr/td/div[

contains(text(), '"+bookName +"')]"))

.findElement(By.xpath("../.."));

bookTableRow.findElement(By.xpath("td[contai

ns(@class,'btn')]/div/button[text()=

'Details']")).click();

Refactored

String bookName = "The Hobbit";

openBookDetails(bookName);

void openBookDetails(String bookName) {

…

}

Extract method

20© 2016

Refactoring in TDD cycle

21© 2016

TestAbstraction

TestDouble(s)

Unit

Test(s)

Dummy Fake

Stub Spy

Mock

22© 2016

Dummy

Customer

Product

Invoiceirrelevant objects

product name

client number

product number

getLineItems()

23© 2016

Stub

WeatherService

WeatherForecast response

(source: http://xunitpatterns.com/Test%20Double%20Patterns.html

getHumidity()

24© 2016

Spy

WeatherService

WeatherForecast response

times called

(source: http://xunitpatterns.com/Test%20Double%20Patterns.html

getHumidity()

25© 2016

Mock

WareHouse

Behaviour verification

(source: http://xunitpatterns.com/Test%20Double%20Patterns.html

Order

Order(prodName, amount)

remove(prodName, amount)

hasInventory(prodName, amount)

fill(wareHouse)

26© 2016

Fake

InMemoryDataBase

dataset/source

(source: http://xunitpatterns.com/Test%20Double%20Patterns.html

HSQLDB

SQLite

27© 2016

Conclusion

• Treat test automation as software development by applying proper naming, SOLID principles and refactoring. This results in:– Increased readability

– Reduced complexity– Increased Maintainability– Increased Extensibility

• Proper refactoring requires unit testing