Q6 of 17 · Framework design

What belongs in a base test class and what should stay out of it?

Framework designMidframework-designbase-testsetupteardownfixtures

Short answer

Short answer: A base test class (or Playwright fixture) holds shared setup/teardown — browser launch, driver initialisation, auth state, and screenshot-on-failure. Business logic, assertions, and test-specific setup must NOT go there.

Detail

Java TestNG example:

public class BaseTest {
    protected WebDriver driver;
    protected LoginPage loginPage;

    @BeforeMethod
    public void setUp() {
        driver = new ChromeDriver(chromeOptions());
        driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
        driver.get(config.getBaseUrl());
    }

    @AfterMethod
    public void tearDown(ITestResult result) {
        if (result.getStatus() == ITestResult.FAILURE) {
            takeScreenshot(result.getName());
        }
        if (driver != null) driver.quit();
    }

    private ChromeOptions chromeOptions() {
        ChromeOptions opts = new ChromeOptions();
        if (config.isHeadless()) opts.addArguments("--headless=new");
        return opts;
    }
}

public class LoginTest extends BaseTest {
    @Test
    public void validLoginRedirectsToDashboard() {
        loginPage = new LoginPage(driver);
        loginPage.login("user@example.com", "pass");
        assertThat(driver.getCurrentUrl()).contains("/dashboard");
    }
}

Playwright fixtures (equivalent pattern):

// fixtures/testFixtures.ts
export const test = base.extend<{ loginPage: LoginPage }>({
  loginPage: async ({ page }, use) => {
    await use(new LoginPage(page));
  },
});

What belongs in base test / fixture:

  • Driver/browser lifecycle
  • Base URL navigation
  • Headless/headed configuration
  • Screenshot on failure
  • Auth state reuse (storageState)

What does NOT belong:

  • Hardcoded test data (belongs in testData/ or test itself)
  • Business-flow steps (belongs in POs or step definitions)
  • Multiple different setups — if 5 tests need login and 5 don't, don't put login in the base class

// WHAT INTERVIEWERS LOOK FOR

Driver lifecycle + screenshot-on-failure as the core base test content. Clear separation: base test = infrastructure, test class = business assertion. The 'don't put login in base class if some tests don't need it' principle.

// Related questions

What is the Page Object Model, and why is it the standard pattern for UI test automation?

Framework design

What is a recommended folder structure for a Playwright or Selenium test framework?

Framework design