Testing Patterns: 11 Test Design Patterns With Examples

1. Four-Phase Test

The structural pattern everything else builds on. The xUnit Test Patterns catalogue answers the question "how do we structure our test logic to make what we are testing obvious?" with a single instruction: structure each test with four distinct parts executed in sequence.

Those parts are fixture setup, exercise SUT, result verification, and fixture teardown. The fourth phase puts the world back into the state you found it, which is what stops one test leaking into the next.

test('cart total includes tax', async () => {
  // 1. fixture setup
  const cart = new Cart({ taxRate: 0.2 });
  cart.add({ sku: 'BOOK-1', price: 100 });

  // 2. exercise SUT
  const total = cart.total();

  // 3. result verification
  expect(total).toBe(120);

  // 4. fixture teardown
  cart.clear();
});

When it stops paying off: modern runners handle teardown through fixtures and hooks, so an explicit fourth phase in every test becomes noise. Move teardown into a fixture as soon as more than two tests repeat it.

2. Arrange-Act-Assert (AAA)

AAA is Four-Phase Test with teardown delegated to the framework. Arrange the state, act on the system, assert the outcome. It is the most widely used structural pattern in unit testing because it maps onto how people describe behavior out loud.

test('applies free shipping above threshold', () => {
  // Arrange
  const order = anOrder().withSubtotal(75).build();

  // Act
  const shipping = calculateShipping(order);

  // Assert
  expect(shipping).toBe(0);
});

One rule keeps it useful: a single act per test. When a test has two act steps it is really two tests, and a failure no longer tells you which behavior broke.

When it stops paying off: never, for unit tests. For long end-to-end journeys the three-block shape becomes artificial, and Given-When-Then or Screenplay reads better.

3. Given-When-Then (GWT)

The same three phases expressed in business language so non-engineers can read and review the specification. It is the structural backbone of behavior-driven development and the reason Cucumber-style tools exist.

Feature: Checkout shipping

  Scenario: Free shipping above the threshold
    Given a customer has 75 dollars of items in the cart
    When they proceed to checkout
    Then shipping is free

GWT is the structural core of behavior-driven development, and Cucumber testing is the most common way teams execute it.

When it stops paying off: when nobody outside the engineering team reads the feature files. At that point the natural-language layer is pure overhead, and plain AAA tests are cheaper to maintain.

4. Test Data Builder

A fluent chain that produces a valid object by default and lets each test override only the field under test. It solves the problem where adding a required constructor argument breaks every test that builds that object.

class CustomerBuilder {
  constructor() {
    this.data = { name: 'Test User', age: 30, country: 'US', verified: true };
  }
  withAge(age) { this.data.age = age; return this; }
  unverified() { this.data.verified = false; return this; }
  build() { return new Customer(this.data); }
}

const aCustomer = () => new CustomerBuilder();

// the test states only what matters to it
const minor = aCustomer().withAge(16).build();

The readability win is that withAge(16) announces the one fact the test depends on. Everything else is deliberately uninteresting. Where the data must outlive the test run, pair this with a test data management approach.

When it stops paying off: when builders acquire conditional logic. A builder with branching is a second implementation of your domain model, and it will drift from the real one.

5. Object Mother

Named factory methods that return canonical, ready-made fixtures. Where a builder composes, an Object Mother hands you a known character from the domain.

const Customers = {
  adult: () => new Customer({ name: 'Ada', age: 34, verified: true }),
  minor: () => new Customer({ name: 'Sam', age: 16, verified: true }),
  unverified: () => new Customer({ name: 'Lee', age: 41, verified: false }),
};

const customer = Customers.minor();

When it stops paying off: at combinatorial growth. The moment you need an unverified minor from Germany you are writing a method per combination, which is precisely the problem Test Data Builder solves. Many suites use both: mothers for the three or four archetypes, builders for variations. The unit testing guide covers where these fixtures fit in the wider practice.

6. Page Object Model (POM)

The single highest-value pattern in UI automation, and the fix for the scenario that opened this article. One class per page or component owns the locators and exposes intent-revealing methods; tests call those methods and never touch a selector.

class LoginPage {
  constructor(page) {
    this.page = page;
    this.username = page.getByLabel('Username');
    this.password = page.getByLabel('Password');
    this.submit = page.getByRole('button', { name: 'Log in' });
  }

  async loginAs(user, pass) {
    await this.username.fill(user);
    await this.password.fill(pass);
    await this.submit.click();
  }
}

// the test never sees a selector
await new LoginPage(page).loginAs('standard_user', 'secret_sauce');

A rename now edits one file. The deeper treatment, including inheritance and component objects, is in the Page Object Model guide, with framework-specific walkthroughs in Playwright Page Object Model and Cypress Page Object Model.

When it stops paying off: when page objects turn into 500-line classes carrying locators, workflow logic, and assertions at once. Assertions in particular belong in the test, not the page object, because a page object that asserts cannot be reused by a test expecting failure.

7. Screenplay Pattern

Screenplay replaces pages with actors who perform tasks using abilities, and ask questions about state. It applies single-responsibility to what POM lumps together, so behavior composes instead of being inherited.

const james = actorCalled('James').whoCan(BrowseTheWeb.using(page));

await james.attemptsTo(
  LogIn.withCredentials('standard_user', 'secret_sauce'),
  AddToCart.theItem('Backpack'),
  Checkout.now()
);

await james.asks(CartTotal.displayed()).shouldEqual('$29.99');

Tasks are reusable across actors, which is what makes multi-role scenarios (an admin and a customer in one test) readable.

When it stops paying off: on small suites. Screenplay's indirection costs more than it saves below roughly a few dozen tests, so adopt it as a response to POM pain rather than as a starting point.

8. Factory Pattern

A classic object-oriented pattern that earns its place in test frameworks by centralising driver and browser creation, so switching from local to cloud execution is a config change rather than an edit across every test.

class BrowserFactory {
  static async create(target = process.env.TARGET) {
    if (target === 'cloud') {
      const caps = {
        browserName: 'Chrome',
        browserVersion: 'latest',
        'LT:Options': {
          platform: 'Windows 11',
          build: 'Design Patterns Demo',
          user: process.env.LT_USERNAME,
          accessKey: process.env.LT_ACCESS_KEY,
        },
      };
      return chromium.connect({
        wsEndpoint:
          'wss://cdp.lambdatest.com/playwright?capabilities=' +
          encodeURIComponent(JSON.stringify(caps)),
      });
    }
    return chromium.launch();
  }
}

When it stops paying off: when the factory becomes a chain of conditionals covering every browser and environment. Split it per concern before it turns into the framework's most-edited file.

9. Fluent Interface

Method chaining where each call returns the next meaningful object, so a workflow reads as one sentence. It is what makes builders pleasant and what lets page objects express navigation.

// each method returns the page you land on
await new LoginPage(page)
  .loginAs('standard_user', 'secret_sauce')   // returns InventoryPage
  .addToCart('Backpack')                      // returns InventoryPage
  .openCart()                                 // returns CartPage
  .checkout();                                // returns CheckoutPage

When it stops paying off: when chains hide branching. A fluent chain that needs an if statement in the middle should be plain sequential calls, because a broken chain produces a stack trace that points at the wrong link.

10. Test Pyramid

Martin Fowler describes the test pyramid as a way of thinking about how different kinds of automated tests should be used to create a balanced portfolio, and states the core rule plainly: you should have many more low-level unit tests than high-level tests running through a GUI.

His reasoning is the argument for every other pattern here. Tests that run end-to-end through the UI are, in his words, brittle, expensive to write, and time consuming to run. Fowler credits Mike Cohn's Succeeding with Agile (2009) for popularising the model.

The practical middle layer is integration testing that exercises business logic beneath the UI, giving most of the confidence of end-to-end testing without the browser. The test pyramid guide covers the layer proportions in detail.

When it stops paying off: as a literal ratio. The pyramid is a heuristic about relative cost and speed, not a quota, and treating it as one leads teams to write low-value unit tests to hit a shape.

11. Contract Testing

The strategy pattern for distributed systems. Each consumer declares the response shape it depends on, and the provider verifies it can satisfy every declared contract, which catches integration breaks without standing up the full system.

It is the pattern that makes a narrow pyramid viable in a microservices estate, because it removes the argument that only end-to-end tests can prove services still talk to each other. See contract testing for the consumer-driven workflow, and microservices testing for how it fits alongside service and end-to-end layers.

When it stops paying off: in a monolith, or where one team owns both sides. The ceremony of publishing and verifying contracts only pays when consumer and provider ship on independent schedules.