Leverage automation testing with design patterns

After analyzing different design patterns applicable in the automation testing area, I’ve decided to share their usage with the local community, more exactly during a meetup organized by Romanian Testing Conference. I would like to express my gratitude to those folks for this opportunity. Now during this article, I’ll share a summary of the presentation, so everyone to get a basic understanding about this concept.

Purpose of this research

Why we need this? Well, it comes about testing we all have to face different challenges like:

  • Multiple platforms/technologies
  • Complex applications
  • Lack of human resources
  • Time
  • False failures
  • Code duplication
  • Spaghetti code

What solutions we have?

  • Hire more people to perform manual tests
  • High cost with many resources
  • Increase the automation coverage with a linear scripting framework
  • Fast test cases implementation
  • Need platform specific tools
  • Low cost with resources
  • Hard maintenance
  • Build your own solid framework

The actual solution -> build your own solid framework, but how?

Maybe using some already existing concepts like:

  • Develop a modular framework
  • Or a data driven one
  • Or Keyword driven
  • Maybe follow the BDD approach
  • And the best one, choose a hybrid solution, which is a mixture between at least two of the already mentioned onces.

But on the top of it, the cherry could be a design pattern, or more.

Design patterns theory

What keywords are defining the design patterns:

  • Typical solutions to commonly existing problems
  • Solve issues using proven solutions
  • Code reusability
  • Readability Minimum effort
  • Solve problems using the OOP principles

The catalog of design patterns

Creational

Provide different object creation related solutions

Structural

Assemble objects into larger structures keeping the code flexible

Behavioral

Focused on the responsibilities between objects

A pattern step by step

Simple factory

  • Factory – a centralized place where things are getting created
  • Simple factory – allow interfaces to create objects without exposing the object creation logic

More details

Factory method

  • Define an interface for creating an object but let subclasses to decide which class to instantiate
  • Let a class to defer instantiation to subclasses
  • In terms of automated testing, it’s good place to start when building a modular framework
  • Each component acts as a wrapper over the application pages

 

Builder

  • Separate the construction of an test from its representation, so the whole construction process can create different representations
  • We need a manager, a builder and a product
  • Manager – construct a specific test using the builder
  • Builder – construct and assemble parts of the test
  • Product – the test to be created

 More details

Singleton

  • Let you create a single class instance of a given type
  • Provide a global access point to it
  • Automation usage: usually during the connectivity with a driver

More details

Page object pattern

  • The most popular pattern in SW automation testing
  • A page is an OOP class that servers as an interface to a page under AUT
  • The main idea is to group all the content of a page in an object, so it will encapsulate:
  • Element IDS

More details

Composite

  • Compose objects into tree structures
  • Automation related
  • Test case design
  • Design small test cases having one or a limited amount of steps
  • Implement more complex tests composed of the previously defined simple tests
  • Test plan definition -> Treat a test plan as an object composed from a set of test cases

Facade

  • Provide a single access point to a set of interfaces or classes
  • It’s an interface for all your available pages
  • Automation usage: on the top of all the available pages apply a single access point -> your facade

More details

Observer

  • Define a relationship between object, if one object state is changed, the others will be notified
  • Automation usage
  • Automated performance testing

State

  • Allow an object to change it’s behavior, when an internal state is changed
  • Automation related:
  • Define each test step as a state
  • Facilitates the test cases debugging in case of complex scenarios
  • It helps us on the identification of any step from a test case
  • Prevent false failures by treating new possible behaviors individually

Strategy

  • Define a family of algorithms, encapsulate each of them and make them interchangeable
  • Strategy pattern give to the client the flexibility to use same object with different algorithms
  • Automation related
  • Define a series of validators which could be accessed by injecting them in a single interface
  • Useful while using different validation algorithms in many contexts

Conclusions

In conclusion I’ve listed our top, but I don’t want to repeat myself so I encourage you to follow our previous related article. For more details see Leverage automation testing with design patterns complete presentation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.