Python pytest from scratch: see how test discovery works, write fixtures for reusable setup, parametrize one test across many inputs, use markers to organize a suite, and measure code coverage with pytest-cov. Every example below was run on real pytest, so the output you see is the output you get.

“Code without tests is broken by design.”

Jacob Kaplan-Moss

You change one line of code, the app still seems to run, and three days later a user reports that something unrelated broke. That sinking feeling is what tests exist to remove. A good test suite is like a smoke alarm in your kitchen: you forget it is there until the moment it saves you from a fire. Python pytest is the tool that wires those alarms into your code, so the second you break something, you hear about it.

Last Updated: July 2026 | Tested on: Python 3.14.6 | Difficulty: Intermediate | Reading Time: 20 minutes

Part 3 starts here. You have spent 65 posts on Python fundamentals and intermediate ground: variables, control flow, data structures, functions, Object-Oriented Programming (OOP), modules, iterators, generators, decorators, and comprehensions. That is a solid base. Part 3 turns you into a professional: testing, type hints, databases, web frameworks, concurrency, packaging, CI/CD (Continuous Integration and Continuous Delivery), and security. The very first skill a professional Python developer reaches for is testing, and in Python that means pytest.

Python ships with unittest in the standard library, but almost nobody picks it for a new project. Python pytest is the community standard. It asks for less boilerplate, it prints far clearer messages when a test fails, and its fixture system is genuinely powerful. You write a plain function with a plain assert inside, and pytest takes care of finding it, running it, and reporting what happened.

By the end of this post you go from zero pytest to a real test suite: fixtures for setup, parametrized tests, markers to slice the suite, a shared conftest.py, and a coverage report that tells you which lines nobody tested. This is a workflow you can drop into every Python project you touch. Once the mechanics feel natural, the next step is writing the test before the code, which is the whole idea behind test driven development in Python.

Tip: click the diagram to open it full screen, then use the zoom and pan controls for a closer look.

The diagram traces the pytest execution pipeline from top to bottom: it discovers your test files by naming convention, selects which tests to run based on markers and filters, sets up fixtures, runs each test function, tears the fixtures back down, and finally prints the results report. Once this pipeline clicks, three things suddenly make sense: why a test file name has to start with test_ (the discovery phase looks for exactly that), why fixtures feel so powerful (they hook straight into the setup and teardown phases), and how a marker like @pytest.mark.slow lets you control the selection phase from the command line.

Install & First Test

A python pytest setup needs just two libraries: pytest itself and pytest-cov for coverage reports. One command installs both.

📄 Terminal: install pytest and the coverage plugin

pip install pytest pytest-cov
pytest --version

▶ Output

pytest 9.1.1

If you see pytest 9.1.1 (or any 9.1.x), you are ready. If the shell says pytest: command not found, your install landed in a different Python than the one on your PATH. The fix is to run it through the interpreter directly: python -m pytest --version. That form always uses the Python you typed, so it is the safe one to reach for whenever a tool seems missing.

The Quick Win: One Function, One Test

Before any theory, let us feel the tool work. Put a tiny function in one file and a test for it in another. The test is just a normal function whose name starts with test_, with a plain assert inside. That is the whole contract. It works like colored stickers on moving day: the movers pick up every box with the sticker, automatically, and touch nothing else. Name it test_ and pytest picks it up.

📄 calculator.py: the code we want to test

# calculator.py
def add(a, b):
    return a + b

def divide(a, b):
    if b == 0:
        raise ValueError("Cannot divide by zero")
    return a / b

📄 test_calculator.py: the tests, written with plain assert

import pytest
from calculator import add, divide

def test_add_positive_numbers():
    assert add(2, 3) == 5

def test_add_negative_numbers():
    assert add(-1, -1) == -2

def test_add_zero():
    assert add(0, 0) == 0

def test_divide_normal():
    assert divide(10, 2) == 5.0

def test_divide_by_zero():
    with pytest.raises(ValueError, match="Cannot divide by zero"):
        divide(10, 0)

Now run pytest -v in that folder. The -v (verbose) flag prints one line per test instead of a row of dots, which is friendlier while you are learning.

▶ Output (pytest -v)

============================= test session starts =============================
platform win32 -- Python 3.14.6, pytest-9.1.1, pluggy-1.6.0 -- C:\tmp\demo\Scripts\python.exe
cachedir: .pytest_cache
rootdir: C:\tmp\demo
collected 5 items

test_calculator.py::test_add_positive_numbers PASSED                     [ 20%]
test_calculator.py::test_add_negative_numbers PASSED                     [ 40%]
test_calculator.py::test_add_zero PASSED                                 [ 60%]
test_calculator.py::test_divide_normal PASSED                            [ 80%]
test_calculator.py::test_divide_by_zero PASSED                           [100%]

============================== 5 passed in 0.19s ==============================

What happened here: You never told pytest where the tests were. It scanned the folder, found the file whose name starts with test_, picked out every function inside that also starts with test_, and ran each one on its own. The header line reports the exact platform, Python version, and pytest version, so a copied output can never lie about what it ran on. The percentage on the right is just progress through the suite.

That last test is the interesting one: pytest.raises is a context manager that says “I expect the code in this block to blow up.” If divide(10, 0) raises the ValueError with a message matching the pattern, the test passes. If it does not raise, pytest fails the test, because the bug you were guarding against came back. Note that your platform line and timing will differ from mine; that is expected and fine.

Fixtures: Reusable Setup and Teardown

Most tests need something prepared before they can run: a fresh database, a logged-in user, a temp file with sample data. A fixture is a function that builds that thing once, and pytest hands it to any test that asks for it. Think of a hotel breakfast buffet. You do not cook your own dosas; you just put “dosa” on your plate and the kitchen has already made them. A fixture is the kitchen. Your test just names what it wants on its plate, and pytest serves it fresh.

You ask for a fixture by adding its name as a parameter to your test function. That is the whole trick. pytest sees the parameter name, finds a matching fixture, runs it, and passes the result in. No imports, no manual wiring. That quiet dependency injection is the heart of python pytest. In the example below, one fixture pre-loads a tiny user store with three made-up users named Aditi, Anvay, and Aviraj, and one test signs up a fourth user named Anvi.

📄 test_user_service.py: fixtures for database-like tests

import pytest

# A simple in-memory user store for demonstration
class UserStore:
    def __init__(self):
        self.users = {}

    def add(self, name, age):
        self.users[name] = {"name": name, "age": age}

    def get(self, name):
        return self.users.get(name)

    def count(self):
        return len(self.users)


@pytest.fixture
def store():
    """Fresh UserStore for each test."""
    return UserStore()


@pytest.fixture
def populated_store(store):
    """Store pre-loaded with sample data."""
    store.add("Aditi", 28)
    store.add("Anvay", 26)
    store.add("Aviraj", 30)
    return store


def test_empty_store(store):
    assert store.count() == 0

def test_add_user(store):
    store.add("Anvi", 25)
    assert store.count() == 1
    assert store.get("Anvi")["age"] == 25

def test_populated_store_count(populated_store):
    assert populated_store.count() == 3

def test_get_existing_user(populated_store):
    user = populated_store.get("Aditi")
    assert user["name"] == "Aditi"
    assert user["age"] == 28

def test_get_missing_user(populated_store):
    assert populated_store.get("Unknown") is None

▶ Output

test_user_service.py::test_empty_store PASSED                            [ 20%]
test_user_service.py::test_add_user PASSED                               [ 40%]
test_user_service.py::test_populated_store_count PASSED                  [ 60%]
test_user_service.py::test_get_existing_user PASSED                      [ 80%]
test_user_service.py::test_get_missing_user PASSED                       [100%]

============================== 5 passed in 0.11s ==============================

What happened here: Every test that lists store as a parameter got its own brand new UserStore, built fresh by the fixture. That is the part that saves you from the worst kind of test bug: one test leaving data behind that quietly changes the result of the next. Fixtures can also stack. populated_store takes store as its own parameter, so pytest builds a fresh store first, hands it to populated_store, which loads three users and passes the loaded store on to the test. A fixture asking for another fixture is exactly how you compose setup without copy-pasting it into every test.

The section title also promised teardown, the cleanup that runs after a test. A fixture handles both halves with one keyword: yield. Everything above the yield is setup, the value you yield is what the test receives, and everything below the yield runs once the test finishes, pass or fail. It is the same idea as borrowing a meeting room: you book it, you use it, and on the way out you clear the whiteboard so the next team walks into a clean room.

📄 test_teardown.py: setup above yield, cleanup below it

import pytest

@pytest.fixture
def temp_log():
    print("\n[setup] opening log file")
    lines = []
    yield lines                     # the test runs at this point
    print(f"[teardown] flushing {len(lines)} lines")

def test_writes_two_lines(temp_log):
    temp_log.append("started")
    temp_log.append("finished")
    assert len(temp_log) == 2

▶ Output (pytest -s -v, the -s flag lets print show)

test_teardown.py::test_writes_two_lines
[setup] opening log file
PASSED[teardown] flushing 2 lines

============================== 1 passed in 0.04s ==============================

What happened here: Read the print order. Setup ran first, then the test body ran (which pushed the result to PASSED), then the teardown ran and reported the two lines it was cleaning up. The -s flag is what let those print calls reach your screen; pytest normally captures output and only shows it when a test fails. Swap that list for a real database connection or an open file, and the line below yield becomes where you close it. The cleanup runs even when the test fails, so you never leak a connection just because an assertion went red.

Parametrize: Many Inputs, One Test

Say you want to test a palindrome checker against ten different words. Copying the test ten times, changing only the input each time, is exactly the kind of dull, error-prone work a tool should do for you. @pytest.mark.parametrize is that tool. You write the test body once and hand it a list of input rows. pytest runs the body once per row and reports each as its own separate test, so a single failing input shows up by name instead of hiding inside a loop.

It is like a checklist on a factory line. One inspector, the same checks, run against every item that rolls past. If item number 7 fails, you know it is item 7, not “something in the batch.” Parametrize is where python pytest starts saving you serious typing.

📄 test_parametrize.py: one test function, many data sets

import pytest

def is_palindrome(s):
    cleaned = s.lower().replace(" ", "")
    return cleaned == cleaned[::-1]


@pytest.mark.parametrize("text, expected", [
    ("racecar", True),
    ("hello", False),
    ("A man a plan a canal Panama", True),
    ("Was it a car or a cat I saw", True),
    ("Python", False),
    ("", True),
])
def test_is_palindrome(text, expected):
    assert is_palindrome(text) == expected


@pytest.mark.parametrize("a, b, expected", [
    (1, 2, 3),
    (0, 0, 0),
    (-5, 5, 0),
    (100, 200, 300),
    (1.5, 2.5, 4.0),
])
def test_add(a, b, expected):
    assert a + b == expected

▶ Output (pytest -v)

test_parametrize.py::test_is_palindrome[racecar-True] PASSED             [  9%]
test_parametrize.py::test_is_palindrome[hello-False] PASSED              [ 18%]
test_parametrize.py::test_is_palindrome[A man a plan a canal Panama-True] PASSED [ 27%]
test_parametrize.py::test_is_palindrome[Was it a car or a cat I saw-True] PASSED [ 36%]
test_parametrize.py::test_is_palindrome[Python-False] PASSED             [ 45%]
test_parametrize.py::test_is_palindrome[-True] PASSED                    [ 54%]
test_parametrize.py::test_add[1-2-3] PASSED                              [ 63%]
test_parametrize.py::test_add[0-0-0] PASSED                              [ 72%]
test_parametrize.py::test_add[-5-5-0] PASSED                             [ 81%]
test_parametrize.py::test_add[100-200-300] PASSED                        [ 90%]
test_parametrize.py::test_add[1.5-2.5-4.0] PASSED                        [100%]

============================= 11 passed in 0.07s ==============================

What happened here: Two test functions and six plus five input rows turned into 11 separate test runs. Look at the names in the square brackets: pytest builds each one from the input values, so [racecar-True] tells you at a glance which row ran. That naming is the real payoff. When one row fails, you read its label and know the exact input that broke, with no debugging archaeology. The empty-string row shows up as [-True] (there is just nothing between the brackets and the dash), which is a tidy way to prove your code handles the empty case too.

Markers: Categorizing Tests

As a suite grows, you stop wanting to run all of it every time. Some tests are slow, some hit the network, some are not finished yet. Markers are labels you stick on tests so you can run a slice instead of the whole thing. Picture the colored tabs you clip onto pages of a thick binder: one color for “read first,” another for “skip for now.” A marker is that tab, and the -m flag is you flipping straight to the color you want.

📄 test_markers.py: tag and filter tests with markers

import pytest

@pytest.mark.slow
def test_heavy_computation():
    """This one takes a while, so we tag it as slow."""
    result = sum(i ** 2 for i in range(1_000_000))
    assert result > 0

@pytest.mark.fast
def test_quick_check():
    assert 1 + 1 == 2

@pytest.mark.skip(reason="Feature not yet implemented")
def test_future_feature():
    assert False  # Will never run

@pytest.mark.xfail(reason="Known bug #42")
def test_known_bug():
    assert 1 / 0  # Expected to fail

📄 pytest.ini: register custom markers to avoid warnings

[pytest]
markers =
    slow: marks tests as slow (deselect with '-m "not slow"')
    fast: marks tests as fast

▶ Run only fast tests: pytest -m fast -v

collected 4 items / 3 deselected / 1 selected

test_markers.py::test_quick_check PASSED                                 [100%]

======================= 1 passed, 3 deselected in 0.05s =======================

What happened here: pytest -m fast told pytest to run only the tests tagged fast and set the other three aside, which the summary calls deselected. Two of the markers in that file do more than label: skip tells pytest never to run a test (handy for a feature that does not exist yet), and xfail means “I know this fails, do not let it break the build” (handy for a known bug you have not fixed).

Run the whole file without -m and you would see those reported as SKIPPED and XFAIL instead of failures. One more thing: the pytest.ini above registers your custom markers. Without it, pytest prints a warning for every unknown marker, which is its way of catching a typo like @pytest.mark.slwo before it silently runs nothing.

conftest.py: Shared Fixtures Across Files

Once you have more than one test file, you will want the same fixture in several of them. Copy-pasting it is the wrong answer. Put it in a file named conftest.py instead, and pytest loads it automatically for every test in that folder and below. No import line needed. Think of conftest.py as the shared supply cabinet for a floor of offices: anyone on the floor can grab from it without asking, and you only stock it once. The example below stocks that cabinet with three sample team members, Sardar, Prathamesh, and Vinay, plus a ready-made temp file.

📄 conftest.py: fixtures available to every test file in the directory

import pytest

@pytest.fixture
def sample_users():
    return [
        {"name": "Sardar", "age": 27, "role": "developer"},
        {"name": "Prathamesh", "age": 24, "role": "designer"},
        {"name": "Vinay", "age": 31, "role": "developer"},
    ]

@pytest.fixture
def temp_file(tmp_path):
    """Create a temporary file using pytest's built-in tmp_path fixture."""
    file = tmp_path / "test_data.txt"
    file.write_text("line1\nline2\nline3\n")
    return file

What happened here: Drop this file next to your tests and any test in the folder can ask for sample_users or temp_file just by naming it as a parameter, with no import at all. The temp_file fixture leans on tmp_path, one of pytest’s own built-in fixtures, which hands you a unique empty folder for each test and deletes it afterward. That is the clean way to test file code: you never touch your real files, and nothing is left lying around when the test finishes.

Code Coverage with pytest-cov

Coverage answers one blunt question: which lines of your code did the tests actually run? A line that no test ever touches is a line nobody has checked, and that is where bugs like to hide. The pytest-cov plugin you installed earlier prints a tidy table. Treat it like the “you missed a spot” mirror at a car wash: it does not prove the car is clean, but it does show you exactly which corners never got touched.

📄 Terminal: run tests with a coverage report

pytest --cov=calculator --cov-report=term-missing test_calculator.py

▶ Output

============================= test session starts =============================
platform win32 -- Python 3.14.6, pytest-9.1.1, pluggy-1.6.0
rootdir: C:\tmp\demo
plugins: cov-7.1.0
collected 5 items

test_calculator.py .....                                                 [100%]

=============================== tests coverage ================================
_______________ coverage: platform win32, python 3.14.6-final-0 _______________

Name            Stmts   Miss  Cover   Missing
---------------------------------------------
calculator.py       6      0   100%
---------------------------------------------
TOTAL               6      0   100%
============================== 5 passed in 0.13s ==============================

What happened here: --cov=calculator told the plugin to watch the calculator module while the tests ran. The table reports 6 statements, 0 missed, 100% covered, and an empty Missing column. That last column is the gold: when coverage is below 100, pytest-cov lists the exact line numbers no test reached, so you know precisely what to write a test for next. One honest warning though: 100% coverage means every line ran at least once, not that every line is correct. A line can be covered by a test that never actually checks the result. Coverage tells you what you forgot to test, not that your tests are good.

Python pytest vs unittest: Why pytest Wins

The short version: think of unittest as a landline and pytest as a smartphone. Both make the call, one just asks far less of you. unittest still works, and pytest can even run your old unittest tests untouched, so moving over is never all-or-nothing. But for anything new, pytest gives you the same result with far less typing and much clearer failure messages. That is why almost every Python project you join already uses it.

Common Mistakes

Two traps catch nearly everyone in their first week with python pytest. Both are easy to avoid once you have seen them.

❌ Mistake 1: Forgetting test file naming convention

# BAD: pytest will not even look at this file
# Filename: calculator_tests.py

# GOOD: name must start with test_ or end with _test
# Filename: test_calculator.py  or  calculator_test.py

Why it bites: pytest finds tests by file name, so calculator_tests.py is silently ignored: it ends in _tests.py, which matches neither test_*.py nor *_test.py. You run pytest, see no tests ran, and assume something is broken when really pytest just never found the file. Stick to test_ at the front and this never happens.

❌ Mistake 2: Tests depending on each other

# BAD: test B relies on test A having run first
shared_state = []

def test_a_adds_item():
    shared_state.append("item")
    assert len(shared_state) == 1

def test_b_checks_item():
    assert shared_state[0] == "item"  # breaks if test_a did not run first

# GOOD: each test builds its own state through a fixture

Why it bites: tests that share a module-level list pass when you run the whole file in order and then fail the moment you run one test on its own, or when pytest runs them in a different order, or in parallel. A test that only works next to its neighbors is not really testing anything. Give each test its own fresh setup through a fixture, and every test can stand on its own.

Wrapping Up

You now have the working core of python pytest: discovery finds anything named test_, fixtures build and clean up whatever each test needs, parametrize turns one function into a table of named cases, markers let you run a slice of the suite, conftest.py shares setup across files, and pytest-cov points at the lines nobody tested. That toolkit covers most of what professional Python teams do with tests every day. Next in the series you flip the workflow with Test Driven Development: write the failing test first, then write the code that makes it pass. To revisit any earlier topic or see the full road ahead, visit the Python + AI/ML tutorial series home.

Frequently Asked Questions

Interview Questions on pytest

These come from real screens and onsites. Practice answering before you read each answer.

Q: A test passes when you run the whole file, but fails when you run it alone with pytest test_file.py::test_name. What is going on?

The test almost certainly depends on state left behind by an earlier test, such as a module-level list or dict that a neighboring test mutated. Run alone, that setup never happened, so the assertion fails. The fix is to make every test build its own state through a fixture, so each one gets a fresh object regardless of run order. This matters in practice because CI systems and plugins like pytest-xdist can run tests in a different order or in parallel.

Q: You run pytest in a project and it reports “collected 0 items” even though the tests folder is full of test files. What do you check first?

Check the naming conventions first: files must match test_*.py or *_test.py, functions must start with test_, and test classes must start with Test and have no __init__. A file like calculator_tests.py matches neither pattern and is silently skipped. If the names are right, check whether a testpaths setting in pytest.ini or pyproject.toml points pytest at the wrong folder, and run python -m pytest to rule out running a different Python environment than the one your tests were written for.

Q: What is the difference between @pytest.mark.skip and @pytest.mark.xfail, and when would you use each?

skip means the test never runs at all: use it when the test cannot run in this environment or the feature does not exist yet. xfail means the test runs but is expected to fail: use it to document a known bug without breaking the build. The key difference shows up when the code gets fixed: an xfail test that suddenly passes is reported as XPASS, and with @pytest.mark.xfail(strict=True) that unexpected pass fails the suite, forcing someone to remove the stale marker.

Q: How does a yield fixture guarantee that cleanup runs even when the test fails?

pytest treats everything after the yield as teardown and runs it once the test finishes, whether the test passed, failed, or errored. Conceptually it behaves like a try/finally wrapped around the test. That is why yield fixtures are the standard place to close database connections, files, and network sessions: a red assertion can never leak the resource. When several fixtures are active, their teardowns run in reverse order of setup.

Q: When would you give a fixture session scope instead of the default function scope, and what is the trade-off?

Use scope="session" for expensive resources you only want to build once per run, like a database connection, a Docker container, or a large dataset loaded from disk. The trade-off is isolation: every test now shares the same object, so if one test mutates it, later tests see the leftovers. The usual pattern is a session-scoped fixture for the expensive connection plus a function-scoped fixture on top of it that resets or rolls back state for each test.

Q: Your module shows 100% coverage in pytest-cov, yet a bug still shipped to production. How is that possible, and what would you change?

Coverage only proves each line executed at least once, not that any test checked the result: a test can call a function and assert nothing meaningful, and the line still counts as covered. Line coverage also misses untested branches, so adding --cov-branch gives a stricter picture. The real fix is better assertions and more input variety: assert on actual outputs, and use @pytest.mark.parametrize to push edge cases like empty input, zero, and negative values through the same code path.

Try It Yourself

Build a StringCalculator class with an add(numbers_string) method that takes a string of comma-separated numbers and returns their sum. Then write a full test suite that covers each rule: a normal case like "1,2,3" returns 6, an empty string returns 0, a single number returns itself, a negative number raises ValueError, and a custom delimiter works. Put the happy-path cases in a @pytest.mark.parametrize list so they each report on their own line, and reach for pytest.raises on the negative-number case. You are done when pytest -v shows every row green and --cov reports 100% on your calculator module. That is the whole python pytest loop: write, run, read the report.

Go deeper: when you outgrow this post, pytest documentation is the next stop.

Related Posts

Previous: Python: pip vs Poetry vs uv vs conda, Package Managers Compared

Next: Python Test Driven Development: Red-Green-Refactor Workflow

Series Home: Python + AI/ML Tutorial Series