Downloaded 44 times
Uploaded byKMS Technology
Common design principles and design patterns in automation testing
The document discusses common design principles and patterns used in automation testing. It covers the SOLID principles: single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. It also discusses the DRY principle and avoiding duplicate code. For design patterns, it describes the page object model (POM) pattern for organizing web page elements and tests. It also discusses using fluent interfaces with the POM pattern. The presentation provides examples and explanations of how to apply these principles and patterns when writing automation tests.
Common design principles and design patterns in automation testing
- 1. TechCon 2017 Khanh Le CommonDesign Principles and Design Patterns in Automation Testing
- 2. Introduction Common Design Principles SOLID DRY Common Design Pattern POM FluentPage ENDING Agenda Summary Q&A
- 3.
- 4. About Me 3+ yearsof experience in telecom and network. 7+ years of experience in software testing (manual, automation, performance). 4+ years of experience in company technical Supporting Solutions, Training and R&D. 2+ year of experience in web security testing and DevOps.
- 5.
- 6. O L S I Single responsibility principle Open/closedprinciple Liskov substitution principle Interface segregation principle SOLID PRINCIPLES DDependency inversion principle
- 7. Every module orclass 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
- 8. Single Responsibility Should break them intoseparate classes base on intended function. With simplicity, it will increase readability, understandability, changeability and maintainability
- 9. Dependency Inversion Principle High-level modules shouldnot depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. Copy Read from Keyboard Printer HLM: High Level Module LLM: Low Level Module How to write a program can read keyboard and then print this?
- 10.
- 11.
- 12.
- 13. Dependency Inversion Principle Copy Readfrom Keyboard Printer HLM LLMWrite to DataBase
- 14. Dependency Inversion Principle Mustmodify Copy Class to interact with “Write to Database” Class
- 15. Dependency Inversion Principle Copy Readfrom Keyboard Include interfaces in High level module Low level modules will implement these interfaces Reader Interface Writer Interface Read from Scanner Printer Write to DataBase LLM HLM
- 16. Dependency Inversion Principle Applythis principle
- 17.
- 18.
- 19.
- 20.
- 21. DRY PRINCIPLE Don't RepeatYourself "Don't write the same code repeatedly" Duplicated steps in test case
- 22. DRY PRINCIPLE Duplicated stepsin test case
- 23.
- 24. POM PATTERN A designpattern 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
- 25.
- 26. POM PATTERN Main TC SubTC Pre- condition Sub TC Step Sub TC Post- condition Page Object API Data base Base Page Page Functions Page Validations Business flow – Pre and Post Main business flow
- 27.
- 28.
- 29.
- 30. POM PATTERN With Pagefactory
- 31. POM PATTERN POM inKatalon – Solution 1
- 32. POM PATTERN In businesslayer : POM in Katalon – Solution 1
- 33. POM PATTERN POM inKatalon – Solution 2
- 34. POM PATTERN POM inKatalon – Solution 2 In business layer :
- 35. 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.
- 36. Fluent Page Pattern POM+ Fluent Interface
- 37. Fluent Page Pattern POM+ Fluent Interface
- 38. Fluent Page Pattern POM+ Fluent Interface Apply this pattern
- 39. Fluent Page Pattern POM+ Fluent Interface Apply this pattern
- 40.
- 41. REFERENCES • http://www.oodesign.com/ • https://www.wikipedia.org/ •https://automatetheplanet.com
- 42.
- 44. 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
- 45.
- 46.
- 47. OPEN/CLOSED PRINCIPLE Execute “Main.java”: Wewant to connect with Oracle Server, what will we do?
- 48.
- 49.
- 50. OPEN/CLOSED PRINCIPLE We willchange the ConnectionManager Class when adding new Database Connection
- 51. OPEN/CLOSED PRINCIPLE Apply thisprinciple
- 52.
- 53. LISKOV SUBSTITUTION PRINCIPLE “Objectsin a program should be replaceable with instances of their subtypes without altering the correctness of that program.” Source: wiki
- 54.
- 55.
- 56. LISKOV SUBSTITUTION PRINCIPLE ReplaceRectangle object to Square object for returning, the issue will come
- 57. LISKOV SUBSTITUTION PRINCIPLE Applythis principle
- 58.
- 59.
- 60.
- 61. INTERFACE SEGREGATION PRINCIPLE “Manyclient-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
- 62.
- 63. INTERFACE SEGREGATION PRINCIPLE WhenAnimal interface has more methods, all classes must implement these methods even if they don’t use.
- 64. INTERFACE SEGREGATION PRINCIPLE Applythis principle
- 65.