Skip to content
SDETRole
SDETRole

Glossary · UI automation

Data-driven testing

Also called: data-driven tests, data-driven test, parameterized tests, parameterized test

Definition

Running the same test logic against many sets of inputs and expected outputs, kept in a table, file or data source rather than copied into each test.

Data-driven testing separates what a test does from the data it does it with. You write the steps once, then feed in rows of data: inputs and the result each one should produce. Every row runs as its own test case with its own pass or fail. It is the natural way to automate the output of techniques like boundary value analysis and equivalence partitioning.

Example (JUnit 5)

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
import static org.junit.jupiter.api.Assertions.assertEquals;

class ShippingFeeTest {

    @ParameterizedTest(name = "order of {0} costs {1} to ship")
    @CsvSource({
        "0.00,   4.99",
        "49.99,  4.99",
        "50.00,  0.00",
        "250.00, 0.00"
    })
    void shippingFee(double orderTotal, double expectedFee) {
        assertEquals(expectedFee, Shipping.feeFor(orderTotal), 0.001);
    }
}

This needs the junit-jupiter-params artifact. Other sources include @ValueSource, @MethodSource and @CsvFileSource for data kept in a CSV file.

Example (Playwright)

Playwright has no special annotation; you generate tests in a loop, giving each a unique title:

import { test, expect } from '@playwright/test';

const cases = [
  { email: '', error: 'Email is required' },
  { email: 'not-an-email', error: 'Enter a valid email' },
];

for (const { email, error } of cases) {
  test(`login rejects "${email}"`, async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(email);
    await page.getByRole('button', { name: 'Sign in' }).click();
    await expect(page.getByRole('alert')).toHaveText(error);
  });
}

Common mistakes

  • Rows that need different steps. If half the rows need an extra click, you have two tests, not one with conditionals.
  • Unreadable names. Include the key inputs in each case’s name so a failure report tells you which row broke.
  • Huge external spreadsheets. Data far from the test is hard to review. Keep small tables inline; move to files only when the data is genuinely large or owned by someone else.
  • Volume over value. Fifty rows from the same equivalence class add run time, not coverage.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →