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.

  • Although interesting, I flagged the question as too broad. It will probably end up as an endless list of arguable design patterns.
    – beatngu13
    Jul 16, 2017 at 10:16
  • @beatngu13 That would be we would need to close other similar questions as well, e.g. about books: sqa.stackexchange.com/questions/42/….
    – dzieciou
    Jul 16, 2017 at 11:34
  • I assume that's why it has been moved to the community wiki (see debate below). At least that's my understing of what types of questions should be avoided.
    – beatngu13
    Jul 16, 2017 at 11:51
  • @beatngu13 Yes. You could flag this question as a candidate for a community wiki or post an answer with community wiki checked up.
    – dzieciou
    Jul 16, 2017 at 19:42

3 Answers 3


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();


var parentPage = require("page");

  • 1
    Thanks! I wonder if this has any name. So the advantage is that the structure of the complex pages is visible both in package structure and in the test script?
    – dzieciou
    Jul 16, 2017 at 19:24
  • 1
    @dzieciou yes. It also makes the interaction readable and easy, e.g. dashboardPage.controlPanel.addFilter()..where controlPanel is a "sub page object" thanks
    – alecxe
    Jul 16, 2017 at 19:32

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

Unit Level Tests

The Test Quadrants

   Int  | Perf/Sec
   Unit | Exploratory
  • Re: Happy and sad path testing. I was rather thinking more of design patterns related to object-oriented programming, describing relations between classes and interfaces. Happy/sad path in more generic approach that can be used in manual testing as well. I should perhaphs update my question.
    – dzieciou
    Jul 15, 2017 at 18:29
  • Yeah, i wasn't sure. the classic design patterns are what they are, when you referenced Page Object I thought maybe you are thinking more generally 'patterns' than the strict definitions. Jul 15, 2017 at 18:31

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:

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.