Application of Design Patterns to Test Automation

    By: Mr. Brian J. Le Suer on Sep 01, 2014

    In this article, Brian Le Suer, CEO of Zeenyx Software, Inc, explores the use of design patterns to solve common problems encountered in automated testing.

    Design patterns are often used in the development of object-oriented software. A design pattern is a description of a commonly occurring problem along with a template for a reusable solution. There are many opportunities to apply design patterns to automated testing to make tests more reusable and easier to maintain. In this article, we'll explore the use of design patterns to solve common problems encountered in automated testing.

    According to the authors of “Design Patterns: Elements of Reusable Object-Oriented Software”, a design pattern has four basic elements: the pattern name, the problem, the solution and the consequences of applying the pattern. The pattern name consists of a few words to describe the pattern. The problem describes when to apply the pattern. It explains the details of the issue and its context. The solution provides an abstract description of the resolution. Because the solution is meant to be reusable, it may provide a template for the design, rather than a concrete implementation. Finally, the consequences examine the costs and benefits of applying the pattern.

    The MultiWaitForWindows Design Pattern

    Pattern Name:

    In the sequence of actions in an automated test, it is possible that the application under test (AUT) may respond to a user stimulus by invoking none, one or more windows based on some characteristic of the transaction or data used in carrying out the transaction.

    Let’s take for example, the transaction to order an item from an ecommerce site. It is possible when adding an item to a shopping cart that the web store might pop up one of many possible windows based on the item to be purchased. For example, the site might try to upsell or cross sell the customer or the site might deliver a message alerting the user to a back order or out of stock condition. While a given application might present a different possible set of windows, the problem itself is a common one.

    The solution to the problem must be able to handle three possible conditions in the transaction flow:


    Login to read the article. Not a member? Create a free account!

    Released: September 1, 2014, 11:10 am | Updated: November 3, 2014, 2:37 pm
    Keywords: IT Strategy Article | Technical Journal | Brian Le Suer | Design | Design Patterns | Development | Object Oriented | Test Automation




    Copyright © 2014 ISUG-TECH. All Rights Reserved
    All material, files, logos and trademarks within this site are copyright their respective organizations

    Terms of Service - Privacy Policy - Contact the Help Desk