6 Selenium Python Libraries Every QA Engineer Should Know

@pytest.mark.parametrize lets you run a single test function across multiple input patterns — a critical tool in real-world projects. Switching authentication patterns in API tests, validating role-based access in UI tests, and more all become cleaner with parametrize. Once you understand pytest.param, indirect, and when to use fixture params instead, your data-driven testing becomes significantly more powerful.

📌 Who This Article Is For

📖 What You’ll Learn in This Article

I have worked as a QA engineer for over 15 years, focusing on API and functional test automation.
From cycling through multiple authentication token patterns in API test suites to validating role-based access across dozens of endpoints, parametrized tests have been central to my work.
This article shares real failure patterns and practical improvements from that experience.

@pytest.mark.parametrize — Quick Recap

Before diving into advanced patterns, let’s confirm the minimal setup.

import pytest

# Specify argument names and a list of value sets
@pytest.mark.parametrize("value, expected", [
    (1,  True),
    (0,  False),
    (-1, False),
])
def test_is_positive(value: int, expected: bool) -> None:
    assert (value > 0) == expected

This runs three test cases automatically. Output names are auto-generated: test_is_positive[1-True], and so on.

5 Advanced Patterns

1. Use pytest.param to Add id and marks

As the number of patterns grows, it becomes hard to tell which case failed.
Adding id (test name) and marks (attributes) with pytest.param makes test output immediately readable.

import pytest
import requests

@pytest.mark.parametrize("payload, expected_status", [
    pytest.param(
        {"username": "admin", "password": "correct"},
        200,
        id="valid_credentials",
    ),
    pytest.param(
        {"username": "admin", "password": "wrong"},
        401,
        id="wrong_password",
    ),
    # Run only smoke tests in CI with: pytest -m smoke
    pytest.param(
        {"username": "", "password": ""},
        400,
        id="empty_credentials",
        marks=pytest.mark.smoke,
    ),
    # Temporarily skipped due to known bug
    pytest.param(
        {"username": "admin", "password": None},
        400,
        id="null_password",
        marks=pytest.mark.skip(reason="Pending fix for Issue #123"),
    ),
    # Known failing case — expected to fail until the bug is fixed
    pytest.param(
        {"username": " ", "password": "pass"},
        400,
        id="whitespace_username",
        marks=pytest.mark.xfail(reason="Whitespace-only username currently passes validation"),
    ),
])
def test_login(payload: dict, expected_status: int) -> None:
    response = requests.post(
        "https://example.com/api/auth/login",  # sample URL
        json=payload,
        timeout=(3, 10),
    )
    assert response.status_code == expected_status

With id, the output becomes test_login[valid_credentials] — clear and searchable.
Without it, you get auto-generated names like test_login[payload0-200], which get confusing fast.

# pytest.ini
[pytest]
markers =
    smoke: Smoke tests (basic sanity checks)
    slow: Tests with long execution time

2. Stack Decorators to Generate Combinations

Stacking multiple @pytest.mark.parametrize decorators generates the Cartesian product of all patterns automatically.

import pytest

# 2 roles × 3 languages = 6 patterns auto-generated
@pytest.mark.parametrize("lang", ["ja", "en", "ko"])
@pytest.mark.parametrize("role", ["admin", "user"])
def test_dashboard_access(lang: str, role: str) -> None:
    # Real-world use: validate role × language access control
    assert lang in ("ja", "en", "ko")
    assert role in ("admin", "user")

3. Use indirect=True to Pass Parameters into Fixtures

With indirect=True, the parameter value is not passed directly to the test function.
Instead, it is forwarded to a fixture of the same name, which then returns the processed result.
This is ideal when you want to switch setup logic based on each parameter.

import pytest
import requests

# Fixture receives the parameter and returns an authenticated session
@pytest.fixture
def authed_session(request: pytest.FixtureRequest) -> requests.Session:
    role: str = request.param  # ← parametrize value arrives here
    credentials = {
        "admin": {"username": "admin_user", "password": "admin_pass"},
        "user":  {"username": "normal_user", "password": "user_pass"},
    }
    cred = credentials[role]
    session = requests.Session()
    res = session.post(
        "https://example.com/api/auth/login",  # sample URL
        json=cred,
        timeout=(3, 10),
    )
    res.raise_for_status()
    session.headers.update({"Authorization": f"Bearer {res.json()['token']}"})
    yield session
    session.close()


# indirect=True forwards the value to the authed_session fixture
@pytest.mark.parametrize("authed_session", ["admin", "user"], indirect=True)
def test_profile_access(authed_session: requests.Session) -> None:
    res = authed_session.get(
        "https://example.com/api/profile",  # sample URL
        timeout=(3, 10),
    )
    assert res.status_code == 200

Without indirect=True, the string "admin" would be passed directly to the test.
Going through the fixture means login logic and teardown are also automated per parameter.

4. Apply indirect to Only Some Arguments (Partial indirect)

You can make only specific arguments go through a fixture while others are passed directly.

import pytest
import requests

@pytest.fixture
def authed_session(request: pytest.FixtureRequest) -> requests.Session:
    role: str = request.param
    session = requests.Session()
    # ... login logic ...
    yield session
    session.close()


# authed_session goes through the fixture; endpoint is passed directly
@pytest.mark.parametrize(
    "authed_session, endpoint",
    [
        pytest.param("admin", "/api/admin/users",   id="admin_users"),
        pytest.param("admin", "/api/admin/reports", id="admin_reports"),
        pytest.param("user",  "/api/profile",       id="user_profile"),
    ],
    indirect=["authed_session"],  # ← specify target argument(s) as a list
)
def test_endpoint_access(authed_session: requests.Session, endpoint: str) -> None:
    res = authed_session.get(
        f"https://example.com{endpoint}",  # sample URL
        timeout=(3, 10),
    )
    assert res.status_code == 200

5. Combine with pytest-xdist for Parallel Execution

pytest-xdist lets you run parametrized test patterns in parallel, which can significantly cut execution time when you have many patterns.

pip install pytest-xdist

# Auto-detect CPU count and parallelize
pytest -n auto

# Or specify the number of workers
pytest -n 4

parametrize vs fixture params — When to Use Which

Both achieve “running tests across multiple patterns”, but they excel in different situations.
Let’s first look at what fixture params code actually looks like.

fixture params — Code Example

import pytest
import requests

# Define roles as fixture params
@pytest.fixture(params=[
    pytest.param("admin",  id="admin_role"),
    pytest.param("editor", id="editor_role"),
    pytest.param("viewer", id="viewer_role"),
])
def role(request: pytest.FixtureRequest) -> str:
    return request.param


# Every test that uses this fixture runs automatically for all 3 roles
def test_can_access_dashboard(role: str) -> None:
    res = requests.get(
        "https://example.com/api/dashboard",  # sample URL
        headers={"X-Role": role},
        timeout=(3, 10),
    )
    assert res.status_code == 200


def test_can_view_profile(role: str) -> None:
    res = requests.get(
        "https://example.com/api/profile",  # sample URL
        headers={"X-Role": role},
        timeout=(3, 10),
    )
    assert res.status_code == 200

Unlike parametrize, every test function that declares role as an argument automatically runs all 3 patterns — no decorator needed on each test.

Comparison Table

Decision flow

Managing Shared Test Data in a Separate File

When multiple test files share the same parameter lists, collecting them in a dedicated data file (e.g. tests/test_data.py) keeps things organized.

Importing directly from conftest.py can technically work, but it creates path-dependency issues and is a common source of ModuleNotFoundError. Separating parameter data into its own file is the safer approach.

# Directory layout
tests/
├── conftest.py      ← fixtures only (no parameter data here)
├── test_data.py     ← centralized parameter data
├── test_login.py
└── test_users.py

# tests/test_data.py
import pytest

VALID_USER_PAYLOADS = [
    pytest.param({"username": "admin",  "password": "admin123"}, id="admin"),
    pytest.param({"username": "editor", "password": "edit456"},  id="editor"),
    pytest.param({"username": "viewer", "password": "view789"},  id="viewer"),
]

INVALID_USER_PAYLOADS = [
    pytest.param({"username": "",      "password": "pass"},  id="empty_username"),
    pytest.param({"username": "admin", "password": ""},      id="empty_password"),
    pytest.param({},                                          id="empty_body"),
]

# tests/test_login.py
import pytest
import requests
from tests.test_data import VALID_USER_PAYLOADS, INVALID_USER_PAYLOADS


@pytest.mark.parametrize("payload", VALID_USER_PAYLOADS)
def test_login_success(payload: dict) -> None:
    res = requests.post(
        "https://example.com/api/auth/login",  # sample URL
        json=payload,
        timeout=(3, 10),
    )
    assert res.status_code == 200


@pytest.mark.parametrize("payload", INVALID_USER_PAYLOADS)
def test_login_failure(payload: dict) -> None:
    res = requests.post(
        "https://example.com/api/auth/login",  # sample URL
        json=payload,
        timeout=(3, 10),
    )
    assert res.status_code in (400, 422)

Separating parameter lists into variables keeps test functions clean and means adding a new pattern only requires editing one place.

Parametrize with Playwright

The same patterns work seamlessly with Playwright. Here’s an example of parametrized login validation in a browser test.

import pytest
from playwright.sync_api import Page

@pytest.mark.parametrize("username, password, expected_url", [
    pytest.param("admin",  "correct", "/dashboard", id="admin_login"),
    pytest.param("user",   "correct", "/home",      id="user_login"),
    pytest.param("admin",  "wrong",   "/login",     id="invalid_password"),
    pytest.param("",       "",        "/login",     id="empty_credentials"),
])
def test_login_redirect(
    page: Page,
    username: str,
    password: str,
    expected_url: str,
) -> None:
    page.goto("https://example.com/login")  # sample URL
    page.fill("[data-testid='username']", username)
    page.fill("[data-testid='password']", password)
    page.click("[data-testid='submit']")
    page.wait_for_url(f"**{expected_url}")
    assert expected_url in page.url

The page fixture is provided by pytest-playwright.
Combining it with @pytest.mark.parametrize lets you validate multiple login scenarios efficiently without relaunching the browser between each case.

7 Common Pitfalls in Real Projects

Frequently Asked Questions (FAQ)

Summary

Mastering @pytest.mark.parametrize‘s advanced patterns lets you grow your test coverage without growing your codebase.
The easiest starting point: add id to your existing pytest.param calls.

Once your patterns are well-organized, adding or removing cases becomes straightforward — and your CI failure messages become actually useful.