Object-oriented programming is a fundamental part of software development and comes with lots of benefit in terms of solving a problem effectively with modularity, reusability and flexibility.  The application of OOPs concepts is very crucial in test architecture to make a solid test base. In this post, I will be covering Abstraction in detail and how can we correlate it in a typical testing framework. 

Abstraction 

As the name implies, refers to hiding non essential details. I am listing the first few questions came to my mind below for better understanding:

- Who is hiding what kind of details here and what did I mean by non essential detail?

- From whom do we want to hide those details?

- How we are going to hide those details?

Let me explain this with a simple example. I clicked on the coffee/tea button on the vending machine and refreshed myself after a long tiring day. As a user of that machine, I really do not care how each component inside the machine are working together to give me that fresh cup of beverage. Let's divide the problem into smaller parts now to get more clarity.

Essential details to share for the maker of the machine with the users: 

  - User interface for selecting tea/coffee 

  - Provision for supplying hot water to the machine

  - Provision for supplying milk to the machine

  - Provision for supplying tea/coffee powder to the machine

Details to hide for the maker of the machine: 

  - How many internal components are used to make the beverage.

  - Which internal component is dependent on what?

  - How each component works independently and together to provide the services above to users.

Data abstraction 

 The process of identifying only the required attributes of an object while discarding the irrelevant details is known as data abstraction. For example in Java, HasMap or HashSet the implementation details are hidden from the users and provided only the operations to interact with the data type. 

Abstraction can be visualised with two forms (as per above example):

- Behaviour abstraction 

- Data abstraction 

How abstraction helps ?

- It gives us ability to conceptualise things keeping the focus on what factors instead of how.

- It allows us to manage complexity at different levels (package, class, interface and method).

- It helps us to design simple with a provision expand later.

How abstraction is implemented?

- In an object oriented programming language, we can implement abstraction using interface or abstract class.

When to use an abstract class?

- If we need to have any default behaviour in the base class and would like to force the sub classes to provide specific behaviour.

When to use an Interface?

- If the client wants to only deal with type without caring about the actual implementation.

- If the design is evolving with frequent changes, interface is preferable because it provides more design flexibility.

Example 1 (from selenium java binding - chrome driver implementation):

WebDriver is an Interface we use in selenium automation framework.

https://github.com/SeleniumHQ/selenium/blob/trunk/java/src/org/openqa/selenium/WebDriver.java 

RemoteWebDriver is a class which implements WebDriver interface.

https://github.com/SeleniumHQ/selenium/blob/trunk/java/src/org/openqa/selenium/remote/RemoteWebDriver.java

ChromiumDriver is a class which extends from RemoteWebDriver (

https://github.com/SeleniumHQ/selenium/blob/1b1872a28016e434b24fccffd8ca0ad9dd684eea/java/src/org/openqa/selenium/chromium/ChromiumDriver.java

ChromeDriver is a class which extends from ChromiumDriver

https://github.com/SeleniumHQ/selenium/blob/1b1872a28016e434b24fccffd8ca0ad9dd684eea/java/src/org/openqa/selenium/chrome/ChromeDriver.java

Example 2 (Creating test data parser for automation framework):

Problem statement: We need to design a test data parser support for a test automation framework. Right now we need to support for excel and json files as data source. Design should be flexible enough to support any new test data source in future (like xml or database).

Solution:






This design is simple enough to support the current requirement and flexible enough to accommodate any future enhancement.

Example 3 (Page object Model):

We can use abstract base page class in page object design pattern.

Example 4 (WebDriver Factory):

We can use Abstract Factory Design pattern to cater the need of creating different browser drivers in the test automation framework.

Hope this post will help to clarify the concepts around Abstraction and use the same in test automation framework confidently. I will be covering the usage of the other 3 pillars of OOPs concept in test automation framework in my upcoming posts.