Common design principles and design patterns in automation testing
•
3 likes•1,193 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Common design principles and design patterns in automation testing
Similar to Common design principles and design patterns in automation testing (20)
More from KMS Technology
More from KMS Technology (20)
Recently uploaded
Recently uploaded (20)
Common design principles and design patterns in automation testing
- 1. TechCon 2017 Khanh Le Common Design Principles and Design Patterns in Automation Testing
- 2. Introduction Common Design Principles SOLID DRY Common Design Pattern POM Fluent Page ENDING Agenda Summary Q&A
- 3. Introduction
- 4. About Me 3+ years of 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.
- 6. O L S I Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle SOLID PRINCIPLES DDependency inversion principle
- 7. 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
- 8. Single Responsibility Should break them into separate classes base on intended function. With simplicity, it will increase readability, understandability, changeability and maintainability
- 9. 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 Keyboard Printer HLM: High Level Module LLM: Low Level Module How to write a program can read keyboard and then print this?
- 13. Dependency Inversion Principle Copy Read from Keyboard Printer HLM LLMWrite to DataBase
- 14. Dependency Inversion Principle Must modify Copy Class to interact with “Write to Database” Class
- 15. Dependency Inversion Principle Copy Read from 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 Apply this principle
- 21. DRY PRINCIPLE Don't Repeat Yourself "Don't write the same code repeatedly" Duplicated steps in test case
- 22. DRY PRINCIPLE Duplicated steps in test case
- 24. POM PATTERN A 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
- 26. 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 Post Main business flow
- 28. POM PATTERN
- 29. POM PATTERN
- 30. POM PATTERN With Page factory
- 31. POM PATTERN POM in Katalon – Solution 1
- 32. POM PATTERN In business layer : POM in Katalon – Solution 1
- 33. POM PATTERN POM in Katalon – Solution 2
- 34. POM PATTERN POM in Katalon – 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. Summary
- 41. REFERENCES • http://www.oodesign.com/ • https://www.wikipedia.org/ • https://automatetheplanet.com
- 42. THANK YOU Q & A
- 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
- 47. OPEN/CLOSED PRINCIPLE Execute “Main.java”: We want to connect with Oracle Server, what will we do?
- 50. OPEN/CLOSED PRINCIPLE We will change the ConnectionManager Class when adding new Database Connection
- 51. OPEN/CLOSED PRINCIPLE Apply this principle
- 53. LISKOV SUBSTITUTION PRINCIPLE “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” Source: wiki
- 56. LISKOV SUBSTITUTION PRINCIPLE Replace Rectangle object to Square object for returning, the issue will come
- 57. LISKOV SUBSTITUTION PRINCIPLE Apply this principle
- 61. 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
- 63. INTERFACE SEGREGATION PRINCIPLE When Animal interface has more methods, all classes must implement these methods even if they don’t use.
- 64. INTERFACE SEGREGATION PRINCIPLE Apply this principle