Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Development principles in
test automation!
David Baak
david.baak@polteq.com
2© 2016
TEST AUTOMATION
==
SOFTWARE DEVELOPMENT
3© 2016
Test
Abstraction
System
Under
Test
Test(s)
4© 2016
What is clean code?
• Readable and maintainable
– Straightforward
– Clear intent
– Logical abstractions
– No surpr...
5© 2016
How does clean code aid test automation?
Smelly code
private String szName;
public void setValueBetweenOneAndThree...
6© 2016
Clean code - Naming
• Names should be self-explanatory
• Names should not carry redundant information or
expose ex...
7© 2015
Clean code – Naming examples
 waitForIt()
 findCustomerOrThrowExceptionIfNotFound(String s)
 int qty_pass_s
 S...
8© 2016
Clean code - SOLID
Single responsibility
Every module or class should have responsibility over a single part
of th...
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 closed
Use inheritance of abstract base classes or composition to reference
other classes...
11© 2016
Clean code - SOLID
• Single responsibility
• Open-closed
Code should be open to extension, but closed to modifica...
12© 2016
Clean code - SOLID
Liskov substitution
Functions that use pointers or references to base classes must be
able to ...
13© 2016
Clean code - SOLID
• Single responsibility
• Open-closed
• Liskov substitution
All the subtypes of a base type mu...
14© 2016
Clean code - SOLID
Interface segration
Split interfaces which are very large into smaller and more specific
ones,...
15© 2016
Clean code - SOLID
• Single responsibility
• Open-closed
• Liskov substitution
• Interface segregation
No client ...
16© 2016
Clean code - SOLID
Dependency inversion
A specific form of decoupling where conventional dependency
relationships...
17© 2016
Clean code - SOLID
• Single responsibility
• Open-closed
• Liskov substitution
• Interface segregation
• Dependen...
18© 2016
Refactoring
“Code refactoring is the process of restructuring existing
computer code – changing the factoring – w...
19© 2016
Refactoring - Automation code example
Original
String bookName = "The Hobbit";
WebElement bookTableRow = driver.f...
20© 2016
Refactoring in TDD cycle
21© 2016
Test
Abstraction
Test
Double(s)
Unit
Test(s)
Dummy Fake
Stub Spy
Mock
22© 2016
Dummy
Customer
Product
Invoice
irrelevant
objects
product name
client number
product number
getLineItems()
23© 2016
Stub
WeatherService
WeatherForecast response
(source: http://xunitpatterns.com/Test%20Double%20Patterns.html
getH...
24© 2016
Spy
WeatherService
WeatherForecast response
times called
(source: http://xunitpatterns.com/Test%20Double%20Patter...
25© 2016
Mock
WareHouse
Behaviour verification
(source: http://xunitpatterns.com/Test%20Double%20Patterns.html
Order
Order...
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
refact...
Upcoming SlideShare
Loading in …5
×

Development principles in test automation!

2,715 views

Published on

Test automation is a prominent part of testing. To further improve our test automation we should look at development practices. One important practice to improve the maintainability of the test automation is to create clean code. Recognizing clean code is quite easy. If it reads like prose and you understand the intent (almost) immediately while you are not the author, then it’s probably clean. However, writing clean code is difficult. This presentation gives you pointers on how to create readable code by using proper naming and refactoring.

Published in: Software
  • Be the first to comment

Development principles in test automation!

  1. 1. Development principles in test automation! David Baak david.baak@polteq.com
  2. 2. 2© 2016 TEST AUTOMATION == SOFTWARE DEVELOPMENT
  3. 3. 3© 2016 Test Abstraction System Under Test Test(s)
  4. 4. 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. 5. 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. 6. 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. 7. 7© 2015 Clean code – Naming examples  waitForIt()  findCustomerOrThrowExceptionIfNotFound(String s)  int qty_pass_s  Seller waitForAlert() int passedScenarios findCustomer(String customerName) Publisher Reseller
  8. 8. 8© 2016 Clean code - SOLID Single responsibility 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.
  9. 9. 9© 2016 Clean code - SOLID Single responsibility An artifact should only have one reason to change Two reasons to change
  10. 10. 10© 2016 Clean code - SOLID Open closed Use inheritance of abstract base classes or composition to reference other classes. Interface is then closed to modification, but the implementation can differ.
  11. 11. 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. 12. 12© 2016 Clean code - SOLID Liskov substitution Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
  13. 13. 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. 14. 14© 2016 Clean code - SOLID Interface segration Split 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. 15. 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. 16. 16© 2016 Clean code - SOLID Dependency inversion A 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. 17. 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 depend on concrete class
  18. 18. 18© 2016 Refactoring “Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external 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 expressive internal architecture or object model to improve extensibility.” (source: https://en.wikipedia.org/wiki/Code_refactoring)
  19. 19. 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. 20. 20© 2016 Refactoring in TDD cycle
  21. 21. 21© 2016 Test Abstraction Test Double(s) Unit Test(s) Dummy Fake Stub Spy Mock
  22. 22. 22© 2016 Dummy Customer Product Invoice irrelevant objects product name client number product number getLineItems()
  23. 23. 23© 2016 Stub WeatherService WeatherForecast response (source: http://xunitpatterns.com/Test%20Double%20Patterns.html getHumidity()
  24. 24. 24© 2016 Spy WeatherService WeatherForecast response times called (source: http://xunitpatterns.com/Test%20Double%20Patterns.html getHumidity()
  25. 25. 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. 26. 26© 2016 Fake InMemoryDataBase dataset/source (source: http://xunitpatterns.com/Test%20Double%20Patterns.html HSQLDB SQLite
  27. 27. 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

×