Design patterns specific for test automation

Question

Software engineering has many design patterns, including Adaptors, Abstract Factories, Decorators etc. Test automation, as a branch of software engineering, can use same patterns but has also its own design patterns, to name a few:

• Page Object - wraps an HTML page, or fragment, with an application-specific API, allowing you to manipulate page elements without digging around in the HTML.
• Screenplay - originally invented to address limitations of Page Object pattern: an Actor have Abilities to perform certain Tasks composed of Actions that interact with Elements of a Screen
• Features and Testers - originally invented by Guava team to test collections: different implementations share similar Features, so one test (caller Tester) for a specific feature can be used to test multiply implementations. It can be used to verify output of end-to-end scenarios as well.

What are other design patterns specific to automating tests?

I am thinking more of design patterns related to object-oriented programming, describing relations between classes and interfaces.

Answer 1

This is probably not a design pattern but more like an organizational/structural pattern.

When having a big test codebase and following the Page Object pattern for WebDriverJS/Protractor testing, we've found out that having a complex Page Object defined as a node "package" (directory with index.js as a main entry point) with child page object exposed through the parent one proved to be quite convenient.

For example:

- page.po
    - index.js
    - subPage1.po.js
    - subPage2.po.js

where index.js defines a parent page object exposing child page objects as object fields:

var subPage1 = require("./subPage1.po"),
    subPage2 = require("./subPage2.po"),

var ParentPage = function () {
    // some fields here

    // child page objects
    this.subPage1 = new SubPage1(this);
    this.subPage2 = new SubPage2(this);
};

module.exports = new ParentPage();

Usage:

var parentPage = require("page");

parentPage.someField.click();
parentPage.subPage1.someChildPageField.sendKeys("Test!");

Answer 2

Happy and sad path testing

Separating out functionality into 'ideal' happy path with correct inputs and selections and no errors, and 'sad' path with user and system errors occurring

Mocking and Stubbing

Vital so that unit tests that would otherwise take a long time can complete quickly

Data Driven Testing

Using complex data sets with different values to drive the testing

The Test Pyramid, more on the bottom, less on top

    Manual
  Integrated
Unit Level Tests

The Test Quadrants

   Int  | Perf/Sec
   _____|___________
   Unit | Exploratory

Answer 3

One of my favorite patterns: Characterization Testing (aka Golden Master Testing) is a neat way to deal with legacy code, which is, according to Michael Feathers, simply code without tests:

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Moreover, Feathers points out that in "[…] nearly every legacy system, what the system does is more important than what it is supposed to do."

As the name suggests, a characterization test aims to characterize the behavior of the test object to protect it against unintended changes, regardless of its correctness. In order to do so, the results of a previous (typically stable) version—the golden master—serve as the oracle for the tests (also known as consistency oracle since it compares the consistency between two versions).

Further reading:

• Michael Feathers: Characterization Testing. Writing tests to describe and fix existing code.
• Bryan Helmkamp: Golden Master Testing. Automatically Validating Millions of Data Points.
• Sandro Mancuso: Testing Legacy Code With Golden Master.*

*: Also shows ApprovalTests, a handy library for Characterization Testing, which is available for Java, C#, VB.NET, PHP, and Ruby.