The document summarizes the SOLID design principles for test automation. It begins by introducing the five SOLID principles - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Each principle is then defined individually and examples are provided for how they could be applied to test automation. The benefits of applying each SOLID principle to test automation are discussed, including improved testability, lower coupling, organization, code maintenance, reusability, and overall architectural stability and flexibility.

1. Presented By: Aditi Varshney
SOLID Design Principles
for Test Automation

2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
Punctuality
Join the session 5 minutes prior
to the session start time. We
start on time and conclude on
time!
Feedback
Make sure to submit a
constructive feedback for all
sessions as it is very helpful for
the presenter.
Silent Mode
Keep your mobile devices in
silent mode, feel free to move
out of session in case you need
to attend an urgent call.
Avoid Disturbance
Avoid unwanted chit chat during
the session.

3. Our Agenda
01 SOLID stands for
02 Introduction to SOLID principle
03 What are these Principles
04 Why to use it in Test Automation
05 Benefits of these Principles

4. S.O.L.I.D Stands For
S- Single Responsibility Principle
O- Open Closed Principle
L- Liskov Substitution Principle
I- Interface Segregation Principle
D- Dependency Inversion Principle

5. Introduction to SOLID Principles
➢ SOLID is an acronym for the first five object-oriented design (OOD)
principles by Robert C. Martin (also known as Uncle Bob) in his
paper in 2000. But the SOLID acronym was introduced later by
Michael Feathers.
➢ SOLID principle is a group of 5 different design patterns.
➢ All five are commonly used by software engineers and provide some
important benefits.
➢ The SOLID principles were developed to combat problematic design
patterns like rigid, fragile, immobile, and viscous software after
development.

6. S- Single Responsibility Principle
“A class should have one, and only one, a reason to change.”
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

7. Examples of Solid Responsibility Principle
a) Page Object Framework implements SRP very well. We are going to have one class
responsible for only one web page in the application. We shouldn’t have a very big class with
many responsibilities like test methods, UI action methods, excel read/write methods.
b) We can have very specific helper classes like ExcelHelper, DatabaseHelper to work with a
excel file or database to implement Data Driven Framework.
c) Selenium API has browser specific driver classes like FirefoxDriver, ChromeDriver,
InternetExplorerDriver. FirefoxDriver has single responsibility to drive the Firefox browser and it
drives the Firefox browser very well.

8. O-Open/closed Principle
“Software entities should be open for extension, but closed for modification”
● The design and writing of the code
should be done in a way that new
functionality should be added with
minimum changes in the existing
code
● The design should be done in a
way to allow the adding of new
functionality as new classes,
keeping as much as possible
existing code unchanged

9. Examples of Open/Closed Principle
Let’s say that you are automating an online store application. You have Customer class to
represent store customers and respective related customer actions. Now, your company has
introduced VIP customer concept to reward loyal customers with discounts and free delivery. To
implement VIP customer behaviour in your automation, OCP suggests that keep the Customer
class same without modifying it and create a new VipCustomer class by inheriting from
Customer class. Now in the VipCustomer class extend the behaviour as required.

10. L- Liskov Substitution Principle
Introduced by Barbara Liskov state that “objects in a program should be
replaceable with instances of their sub-types without altering the
correctness of that program”
● If a program module is using a Base
class, then the reference to the Base
class can be replaced with a Derived
class without affecting the functionality
of the program module
● We can also state that Derived types
must be substitutable for their base
types

11. Examples of Liskov Substitution Principle
Considering the same example of automating an online store application with Customer and
VIP Customer categories, let’s say there is a method calculateDeliveryCharge(Customer
customer, OrderInfo orderInfo) which calculates delivery charge when customer and order
information is passed. When we pass Customer object to calculateDeliveryCharge() method
with order information, it should return delivery charge. Note that we are providing free delivery
to VIP Customers. So, when we pass VipCustomer object for customer argument to
calculateDeliveryCharge() method with order information, the program/code should work
properly without changing its behaviour and shouldn’t throw any exceptions.

12. I- Interface segregation Principle
“ Many client-specific interfaces are better than one general-purpose
interface ”
● We should not enforce clients to
implement interfaces that they don't
use. Instead of creating one big
interface we can break down it to
smaller interfaces

13. Examples of Interface segregation Principle
Selenium API has good examples of ISP. Selenium API has a number of very fine grained, role
based client specific interfaces like WebDriver, WebElement, Alert. We should favour role based
interfaces instead of generic interfaces.

14. D- Dependency Inversion Principle
One should “depend upon abstractions, [not] concretions"
● Abstractions should not depend on
the details whereas the details should
depend on abstractions
● High-level modules should not
depend on low level modules

15. ➢ Its main focus is to create loosely coupled architectures with a
high level of maintainability.
➢ It make code easier to understand, easier to test, easier to
maintain and more flexible
➢ It helps us to write testable code by using good designing
principles.
➢ It reduce dependencies so that we can change one area of
software without impacting others
Why we use Solid Principle In Test Automation

16. Benefits of SOLID
1) Single Responsibility Principle
➢ Testing – A class with one responsibility will have far fewer test cases.
➢ Lower coupling – Less functionality in a single class will have fewer dependencies.
➢ Organization – Smaller, well-organized classes are easier to search than monolithic ones.

17. 2) Open/Closed Principle
➢ The benefits of adhering to the OCP can potentially streamline code maintenance and
minimizing risk of breaking the existing code base.
➢ One benefit is that programmers do not have to reinvent the wheel if they can extend upon
behaviors that have already been defined.
➢ Only new changes need to deploy instead of entire code Base in the production
➢ Software entities should be ‘closed for modification’ because making changes directly to
those entities may result in unwanted bug in the system.

18. 3) Liskov Substitution Principle
➢ Code that adheres to LSP is loosely dependent to each other and
encourages code reusability

19. 4) Interface Segregation Principle
➢ Faster Compilation
➢ Maintainability
➢ Reusability

20. 5) Dependency Inversion Principle
➢ Finally, DIP when applied correctly gives us the flexibility and stability at
the level of the entire architecture of our application.
➢ Our application will be able to evolve more securely and become stable
and robust.

21. DEMO

22. Q/A

23. Thank You