Test Automation Design Patterns Visualizer

Page Object Model (POM)

The Page Object Model wraps each page or component in a class that exposes actions (loginPage.login(user, pass)) and hides the locators. When the UI changes, you fix one page object, not fifty tests. This is the single most important pattern in UI automation and the one every interview probes.

Factory pattern for drivers

A DriverFactory centralises how WebDriver instances are created, so switching from Chrome to Firefox, or local to a remote grid, is one change in one place. It keeps browser-setup logic out of your tests and makes cross-browser runs trivial.

Singleton and ThreadLocal

A naive Singleton WebDriver breaks under parallel execution because every thread shares one browser. The correct pattern is a ThreadLocal driver: one isolated instance per thread, which is why this comes up whenever parallel testing does.

Builder pattern for test data

The Builder pattern constructs complex test data readably: new UserBuilder().withRole("admin").withVerifiedEmail().build(). It beats constructors with ten arguments and makes each test state its intent, keeping data setup clean as the suite grows.

How to use this tool

1. Pick a pattern in the tool and see it applied to a sample framework.
2. Compare a test written with and without the Page Object Model.
3. See why a Singleton driver fails in parallel and how ThreadLocal fixes it.
4. Build a test-data object with the Builder pattern step by step.

Worked example

A Page Object hides locators behind intention-revealing methods:

public class LoginPage {
    private final WebDriver driver;
    private final By user = By.id("username");
    private final By pass = By.id("password");
    private final By submit = By.cssSelector("button[type=submit]");

    public LoginPage(WebDriver driver) { this.driver = driver; }

    public HomePage login(String u, String p) {
        driver.findElement(user).sendKeys(u);
        driver.findElement(pass).sendKeys(p);
        driver.findElement(submit).click();
        return new HomePage(driver);
    }
}

Common mistakes to avoid

• Putting assertions inside page objects — page objects model the page, tests own the assertions.
• A shared Singleton WebDriver that breaks the moment tests run in parallel.
• Constructors with many arguments instead of a Builder for test data.
• Over-engineering: adding patterns a small framework does not need yet.

Frequently asked questions

Related guides & tools