Data-Driven Testing: Complete Guide with Python

Data-driven testing (DDT) means writing a test once and running it against many sets of input data and expected results stored outside the test logic: in a parameter list, a CSV or JSON file, a spreadsheet or a database. In Python, the simplest way to do it is pytest's @pytest.mark.parametrize decorator. This guide explains when DDT is worth it, how to implement it with pytest and each data source, and how to manage test data without making the suite fragile.

What is data-driven testing?

Data-driven testing is a test design approach in which the test logic is written once and the inputs and expected outputs come from a separate data set. The same scenario, for example "apply a discount code and check the total", runs once per data row. Adding a case means adding a row, not writing new code.

The approach increases coverage without duplicating test code, and it lets people who do not write code, such as business analysts, review or extend the test cases directly in the data file.

When should you use data-driven testing?

Use it when the same behaviour must be checked against many input combinations: calculations, validation rules, pricing, permissions, form fields or API payloads. Avoid it when each case needs different steps: forcing different scenarios into one parameterised test produces conditional logic that is harder to read than separate tests.

How do you do data-driven testing with pytest?

Decorate the test function with @pytest.mark.parametrize, name the arguments and pass a list of tuples. pytest generates one test item per tuple, so each case passes or fails on its own and appears separately in the report.

For example, @pytest.mark.parametrize("price, discount, expected", [(100, 0, 100), (100, 10, 90), (100, 25, 75)]) above def test_discount(price, discount, expected) produces three tests. Useful options:

Avoid the alternative of looping over the data inside a single test: the first failing row stops the loop, the remaining rows never run, and the report shows one failure instead of telling you which cases broke.

Which data source should you use: CSV, JSON, Excel or a database?

Pick the source according to who maintains the data and how structured it is. Inline lists are best while the data set is small; move to a file when it grows or when non-developers need to edit it.

How do you load a CSV or JSON file into pytest?

Read the file at collection time, convert each row into a tuple or pytest.param, and pass the resulting list to parametrize.

1. Store the file next to the tests, for example in tests/data/discounts.csv, and version it in Git with the code.
2. Write a small loader function that opens the file with csv.DictReader or json.load and converts each value to the right type.
3. Give each row an identifier column and use it as the test id.
4. Call the loader in the decorator: @pytest.mark.parametrize("case", load_cases("discounts.csv"), ids=lambda c: c["id"]).
5. Fail loudly if the file is empty or a column is missing, so a broken data file never results in zero tests passing silently.

Does data-driven testing work for API and Playwright tests?

Yes. For API tests, parameterise the payload and the expected status code, and run each row through requests or the HTTP client of your framework; our API testing tools comparison shows which client fits your stack. In Playwright Test (TypeScript), the documented approach is to loop over an array of data and declare one test() per item, each with a unique title. In pytest-playwright, parametrize works exactly as with any other pytest test.

How do you manage test data safely?

Keep every test independent, generate what you can and never copy personal data from production.

When the data comes from pipelines rather than from test files, you also need checks on the data itself; see our guide to data quality testing and validation.

How many data rows do you need?

Fewer than you think: one row per equivalence class plus the values at each boundary. Equivalence partitioning groups inputs that the system should treat the same way; boundary value analysis tests the values at the edges of each group, where bugs cluster. Both techniques are part of the ISTQB Foundation Level syllabus. For a discount valid from 1 to 50 items, test 0, 1, 50 and 51 rather than twenty random quantities.

Is data-driven testing the same as keyword-driven testing?

No. Data-driven testing varies the data while the steps stay fixed; keyword-driven testing describes the steps themselves as reusable keywords, as in Robot Framework. Behaviour-driven development (BDD) tools such as Cucumber or pytest-bdd support both ideas: "Scenario Outline" with an "Examples" table is data-driven testing written in Gherkin.

Frequently asked questions