What Is Pytest in Python? Complete Explanation 2026
Pytest is a third-party Python test framework, not a language or part of the standard library. Learn how it works, how to install it, and write your first test.
What Is Pytest in Python? Complete Explanation
If you have spent any time searching for "what is pytest" you have probably run into a surprising amount of confusion. Some tutorials talk about it as if it were a separate programming language. Others assume you already know everything and dive straight into fixtures and parametrization. And a lot of beginners genuinely wonder whether pytest is something built into Python that they somehow missed. Let us clear all of that up in one place. Pytest is a third-party testing framework for Python. It is a library you install with pip, written in Python, that you use to write and run automated tests for Python code. It is not a language. It is not a separate runtime. It is not part of the Python standard library. It is a package, like requests or numpy, that happens to be the single most popular way to test Python code in 2026.
The confusion is understandable. Pytest tests are written in a style that looks slightly different from ordinary Python scripts, the pytest command behaves like its own tool, and the framework does a lot of "magic" behind the scenes that can feel like a separate system. But once you understand that pytest is just Python code calling a Python library, the whole thing becomes far less mysterious. In this guide we will walk through exactly what pytest is, how it differs from Python's built-in unittest module, how to install it, how to write and run your very first test, how its famous fixtures and assert rewriting work under the hood, and the questions people most commonly type into search engines about it. By the end you will be able to explain pytest to someone else and write working tests yourself.
If you want to skip ahead and give an AI coding agent expert pytest knowledge, you can install the pytest patterns skill and have Claude Code, Cursor, or Copilot write idiomatic pytest tests for you. But first, let us understand the fundamentals.
Pytest Is a Framework, Not a Language
The single most important thing to internalize: pytest is a Python testing framework, distributed as a PyPI package named pytest. When you write a pytest test, you are writing plain Python. There is no new syntax to learn at the language level. Everything you already know about Python functions, classes, imports, and expressions still applies.
A "framework" in this context means a structured set of tools and conventions that handle the boring, repetitive parts of testing for you: discovering which functions are tests, running them, reporting which passed and failed, and giving you helpers for setup and teardown. Without a framework you would have to write all of that orchestration yourself. Pytest does it so you can focus on describing what your code should do.
Compare it to other well-known frameworks in other languages. In JavaScript you have Jest and Vitest. In Java you have JUnit. In Ruby you have RSpec. In C# you have xUnit and NUnit. Pytest occupies the same role in the Python ecosystem. None of these are languages either; they are libraries that give structure to your tests.
Here is the mental model in a single table:
| Misconception | Reality |
|---|---|
| "Pytest is a language" | Pytest is a Python library; tests are written in Python |
| "Pytest is built into Python" | No. It is a third-party package you install with pip |
| "Pytest replaces Python" | No. It runs on top of CPython like any other library |
| "Pytest has its own syntax" | It uses plain assert and ordinary functions; the only special things are decorators and fixtures, which are normal Python |
| "I need pytest to run Python" | No. You only need it when you want to write automated tests |
Is Pytest Part of the Python Standard Library?
No. Pytest is not part of the Python standard library. This is one of the most common questions people ask, so it deserves a direct, unambiguous answer. When you install Python from python.org, you get a module called unittest (sometimes nicknamed PyUnit) baked into the standard library. You do not get pytest. To use pytest you must install it separately.
You can verify this yourself. Open a fresh Python interpreter on a clean install and try to import each one:
import unittest # works on any standard Python install
import pytest # raises ModuleNotFoundError until you pip install it
The first import succeeds because unittest ships with Python. The second fails with ModuleNotFoundError: No module named 'pytest' until you install the package. This is the clearest possible demonstration that pytest lives outside the standard library.
So why is pytest so dominant if Python already ships with a testing module? Because pytest is dramatically less verbose and far more powerful. The standard library's unittest is modeled on Java's JUnit, which means lots of boilerplate: you subclass unittest.TestCase, you use methods like self.assertEqual(), and you organize everything into classes even for trivial checks. Pytest lets you write a test as a plain function with a plain assert statement. That difference compounds across thousands of tests, which is why the overwhelming majority of modern Python projects, including major open-source ones, use pytest.
Installing Pytest
Because pytest is a third-party package, you install it from the Python Package Index (PyPI) using pip. The recommended approach in 2026 is to install it inside a virtual environment so it does not pollute your global Python.
# Create and activate a virtual environment
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install pytest from PyPI
pip install pytest
# Confirm the version
pytest --version
After running these commands you will see something like pytest 8.x.y. If you are using a modern project manager such as uv, Poetry, or PDM, you would add pytest as a development dependency instead:
# With uv (very popular in 2026)
uv add --dev pytest
# With Poetry
poetry add --group dev pytest
The key point remains the same regardless of tool: you are pulling a separate package into your environment. Nothing about installing pytest changes the Python language itself.
Writing Your First Pytest Test
Now for the fun part. A pytest test is, in its simplest form, a Python function whose name starts with test_ that contains an assert statement. Create a file called test_math.py:
# test_math.py
def add(a, b):
return a + b
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, 7) == 7
That is a complete, runnable test suite. Notice what is not here: no class to subclass, no special assertion methods, no imports from pytest at all for this basic case. You just write a function and assert what you expect to be true.
To run it, use the pytest command in the directory containing the file:
pytest test_math.py
You will see output similar to:
========================= test session starts =========================
collected 3 items
test_math.py ... [100%]
========================== 3 passed in 0.01s ==========================
Each green dot represents a passing test. If an assertion fails, pytest replaces the dot with an F and prints a detailed breakdown showing exactly which values did not match.
How Pytest Discovers Tests
You never tell pytest which functions are tests by registering them anywhere. Instead, pytest discovers them automatically by following naming conventions. This is one of the things that can feel like magic until you know the rules. When you run pytest, the framework walks the directory tree and collects:
| Item | Default convention pytest looks for |
|---|---|
| Test files | Files named test_*.py or *_test.py |
| Test functions | Functions prefixed with test_ |
| Test classes | Classes prefixed with Test (no __init__ method) |
| Test methods | Methods inside those classes prefixed with test_ |
So if you run a bare pytest in your project root, it finds every test_*.py file, imports it, identifies every test_ function, and runs them all. You can override these conventions in a configuration file, but the defaults work for the vast majority of projects. This convention-over-configuration approach is a big reason pytest feels lightweight.
How Pytest Works Under the Hood: Assert Rewriting
When people ask "how does pytest work," the part that surprises them most is the assertion reporting. In plain Python, a failing assert x == y just raises a bare AssertionError with no detail. Yet pytest somehow shows you both values, the difference, and context. How?
Pytest uses a technique called assertion rewriting. When it imports your test modules, it intercepts them at the import-hook level and rewrites the bytecode of your assert statements before they execute. The rewritten version captures the left and right operands, the operator, and intermediate values, so that when an assertion fails pytest can produce a rich, human-readable explanation. This all happens transparently; you write a normal assert and pytest enhances it.
Here is what a failing test looks like thanks to assert rewriting:
def test_string_match():
expected = "hello world"
actual = "hello pytest"
assert actual == expected
def test_string_match():
expected = "hello world"
actual = "hello pytest"
> assert actual == expected
E AssertionError: assert 'hello pytest' == 'hello world'
E - hello world
E + hello pytest
You get a diff, not just a "test failed" message. This introspection is a core part of the pytest experience and explains why developers find it so much more productive than bare asserts or the verbose self.assertEqual calls of unittest.
Pytest Fixtures: Reusable Setup
The other pillar of pytest is fixtures. A fixture is a function, decorated with @pytest.fixture, that provides data or resources to your tests. Instead of duplicating setup code at the top of every test, you define it once as a fixture and request it by adding it as a parameter to your test function. Pytest sees the parameter name, finds the matching fixture, runs it, and injects the result. This is dependency injection.
import pytest
@pytest.fixture
def sample_user():
# Setup: create the resource the test needs
user = {"name": "Ada", "role": "admin", "active": True}
return user
def test_user_is_admin(sample_user):
assert sample_user["role"] == "admin"
def test_user_is_active(sample_user):
assert sample_user["active"] is True
Both tests receive a fresh sample_user without repeating the setup. Fixtures can also handle teardown using yield: code before the yield runs as setup, code after it runs as cleanup once the test finishes.
@pytest.fixture
def db_connection():
conn = open_connection() # setup
yield conn # hand the resource to the test
conn.close() # teardown, runs after the test
Fixtures support scopes (function, class, module, session) so you can control how often the setup runs. We cover fixture scopes, markers, and configuration in depth in our pytest best practices guide. For a broader walkthrough, see the complete pytest testing guide.
Pytest vs unittest: A Direct Comparison
Since unittest is the standard-library option and pytest is the third-party challenger, the comparison comes up constantly. The good news is that pytest can run unittest-style tests too, so adopting pytest does not mean rewriting existing unittest suites. Here is how the same trivial test looks in each:
# unittest style (standard library)
import unittest
class TestAddition(unittest.TestCase):
def test_add(self):
self.assertEqual(2 + 3, 5)
if __name__ == "__main__":
unittest.main()
# pytest style (third-party)
def test_add():
assert 2 + 3 == 5
The pytest version is three lines instead of seven, with no class, no inheritance, and no special assertion method. Here is the broader comparison:
| Feature | unittest (stdlib) | pytest (third-party) |
|---|---|---|
| Installation | Built in | pip install pytest |
| Test style | Classes subclassing TestCase | Plain functions |
| Assertions | self.assertEqual(), self.assertTrue(), etc. | Plain assert |
| Failure detail | Minimal | Rich, rewritten introspection |
| Setup/teardown | setUp / tearDown methods | Fixtures with dependency injection |
| Parametrization | Verbose subtests | @pytest.mark.parametrize |
| Plugin ecosystem | Limited | 1000+ plugins (pytest-cov, pytest-xdist, pytest-mock) |
| Can run the other style | No | Yes, runs unittest tests too |
For a deeper side-by-side, read Python unittest vs pytest and unittest vs pytest 2026. The short version: unittest is fine and always available, but pytest's lower boilerplate, richer output, fixtures, and plugin ecosystem make it the default choice for new projects.
Running Pytest and Reading Its Output
Once you have tests, you run them with the pytest command. There are several ways to invoke it, and understanding the output is part of understanding what pytest is.
pytest # discover and run every test in the project
pytest tests/ # run all tests under a directory
pytest test_math.py # run one file
pytest test_math.py::test_add_zero # run one specific test
pytest -v # verbose: print each test name and result
pytest -k "add" # run only tests whose name contains "add"
A passing run shows a dot per test and a green summary line. A failing run is where pytest's value becomes obvious. Instead of a bare stack trace, you get the failing line marked with >, the actual versus expected values, and a short traceback:
=================================== FAILURES ===================================
_______________________________ test_add_zero ________________________________
def test_add_zero():
> assert add(0, 7) == 8
E assert 7 == 8
E + where 7 = add(0, 7)
test_math.py:11: AssertionError
========================= 1 failed, 2 passed in 0.02s =========================
This is the assertion rewriting from earlier doing its job: it shows you that add(0, 7) returned 7 but the test expected 8. You do not need a debugger to see what went wrong. This rich, readable feedback is a defining characteristic of pytest as a framework and a big reason it feels productive.
Pytest Also Supports Test Classes
While the headline feature is writing tests as plain functions, pytest also lets you group related tests into classes for organization, without the heavyweight inheritance unittest demands. A pytest test class is just a class whose name starts with Test, with no base class to inherit and no __init__ method.
class TestCalculator:
def test_add(self):
assert 2 + 3 == 5
def test_subtract(self):
assert 5 - 2 == 3
def test_multiply(self):
assert 4 * 2 == 8
Notice there is no unittest.TestCase to subclass and no special assertion methods; you still use plain assert. Classes are purely an organizational convenience here, useful when several tests share a fixture or logically belong together. This flexibility, supporting both functions and lightweight classes, is part of why pytest fits projects of every size, from a single script to a large application test suite.
Why Pytest Dominates Python Testing in 2026
Pytest's popularity is not an accident. Several factors compound to make it the standard:
First, low ceremony. A test is just a function. New contributors can write their first test in minutes without learning class hierarchies. Second, the plugin ecosystem. There are over a thousand pytest plugins. Need code coverage? pytest-cov. Need to run tests in parallel across CPU cores? pytest-xdist. Need mocking integrated with fixtures? pytest-mock. Need to retry flaky tests? pytest-rerunfailures. This extensibility means pytest grows with your needs. Third, powerful fixtures and parametrization let you express complex setups and data-driven tests cleanly. Fourth, backward compatibility: it runs your old unittest and nose tests, so migration is incremental.
The result is a virtuous cycle. Because most projects use pytest, most tooling, CI templates, and tutorials assume pytest, which makes more new projects choose pytest. If you are learning Python testing today, pytest is the framework to learn.
Frequently Asked Questions
What is pytest in Python?
Pytest is a third-party testing framework for Python, distributed as a pip-installable package on PyPI. It lets you write automated tests as plain Python functions using ordinary assert statements, then discovers and runs them with the pytest command. It is not a programming language and not part of Python's standard library; it is a library written in Python that you add to your project to test Python code.
Is pytest part of the Python standard library?
No, pytest is not part of the Python standard library. A standard Python installation ships with the built-in unittest module, but pytest must be installed separately using pip install pytest. You can confirm this because import unittest works on a clean install while import pytest raises ModuleNotFoundError until the package is installed from PyPI.
Is pytest a programming language?
No, pytest is not a programming language. It is a Python library, so every pytest test is written in plain Python. The only pytest-specific elements you encounter are decorators like @pytest.fixture and @pytest.mark.parametrize, which are normal Python decorators, plus the pytest command-line runner. There is no separate syntax or runtime to learn beyond ordinary Python.
How does pytest work under the hood?
Pytest works by discovering test files and functions through naming conventions (test_*.py files and test_ functions), then importing and executing them. During import it performs assertion rewriting, rewriting the bytecode of your assert statements so that failures produce detailed diffs of the compared values. It also resolves fixtures via dependency injection, matching fixture function names to test parameters.
Do I need pytest to run Python code?
No, you do not need pytest to run Python code. Python runs perfectly without it. You only install pytest when you want to write and run automated tests for your code. Pytest is a development and testing tool, not a runtime requirement, so it typically lives in your development dependencies and is not shipped to production.
What is the difference between pytest and unittest?
Unittest is Python's built-in testing framework that requires subclassing TestCase and using methods like self.assertEqual(). Pytest is a third-party framework that uses plain functions and plain assert statements, offers richer failure output through assertion rewriting, provides fixtures for setup, and supports a large plugin ecosystem. Pytest can also run existing unittest tests, making migration incremental.
How do I install pytest?
Install pytest from PyPI using pip, ideally inside a virtual environment: run python -m venv .venv, activate it, then pip install pytest. Verify the install with pytest --version. If you use a modern dependency manager you can run uv add --dev pytest or poetry add --group dev pytest to add it as a development dependency instead.
What version of pytest should I use in 2026?
In 2026 you should use the latest pytest 8.x release, which is the current major line and supports modern Python versions (3.9 and newer). Pin a recent version in your dependency file and let it update within the 8.x range. Using the latest stable release ensures you get current bug fixes, performance improvements, and compatibility with the newest plugins and Python releases.
Conclusion
Pytest is a third-party Python testing framework, not a language and not part of the standard library. You install it with pip install pytest, write tests as plain functions with assert statements, and run them with the pytest command. Under the hood it discovers tests by naming convention, rewrites your assertions for rich failure output, and injects fixtures through dependency injection. Compared to the built-in unittest module it is far less verbose and far more extensible, which is why it dominates Python testing in 2026.
Ready to go deeper? Read our pytest best practices guide for fixtures, markers, and configuration, or compare frameworks in unittest vs pytest 2026. To give your AI coding agent expert pytest knowledge so it writes idiomatic tests automatically, browse the QA skills directory:
npx @qaskills/cli add pytest-patterns
Explore all 450+ testing skills at qaskills.sh/skills and start writing better Python tests today.