Pytest Built-in Fixtures

Eric Chen — Sun, 09 Aug 2026 22:28:21 +0000

As I've been onboarding to my new position, I've been reviewing some of my coworker's code. I learned that pytest 1) has some built-in fixtures, and 2) they are really useful!

First, briefly, what are fixtures? When writing pytest tests, it's pretty frequent to write fixtures for reusability. They are used to set up tests. For example, a common fixture is:

@pytest.fixture()
def dataset_path():
    return "/dataset/imagenet/train"

def test_dataloader(dataset_path):
    dataloader = DataLoader(dataset_path)
    assert dataloader is not None

When test_dataloader runs, pytest sees it takes a dataset_path argument, finds the matching fixture, and injects the returned path automatically.

What is really cool is that pytest actually comes with some pretty useful built-in fixtures. Two are tmp_path and monkeypatch.

tmp_path gives a random path (a pathlib.Path object) unique for each test. For example, a minimal example is:

from pathlib import Path

def test_path1(tmp_path: Path):
    print(tmp_path)

def test_path2(tmp_path: Path):
    print(tmp_path)

Terminal:

uv run pytest -s
======================================================== test session starts =========================================================
platform darwin -- Python 3.11.15, pytest-9.1.1, pluggy-1.6.0
rootdir: /Users/user/Developer/til
configfile: pyproject.toml
collected 2 items

test/random_tst/random_test.py 
/private/var/folders/5t/n5nrkl1n77q5vlvsxys89hhc0000gn/T/pytest-of-user/pytest-4/test_path10
.
/private/var/folders/5t/n5nrkl1n77q5vlvsxys89hhc0000gn/T/pytest-of-user/pytest-4/test_path20
.

While tmp_path is straightforward, monkeypatch is like a Swiss army knife.

From the pytest documentation, it can set and delete attributes of objects, set and delete items in a map, set and delete environment variables, etc.:

monkeypatch.setattr(obj, name, value, raising=True)
monkeypatch.delattr(obj, name, raising=True)
monkeypatch.setitem(mapping, name, value)
monkeypatch.delitem(obj, name, raising=True)
monkeypatch.setenv(name, value, prepend=None)
monkeypatch.delenv(name, raising=True)
monkeypatch.syspath_prepend(path)
monkeypatch.chdir(path)
monkeypatch.context()

source

Here is one example to set environment variables:

import os

def test_monkeypatch(monkeypatch):
    print(f"TEST_ENV: {os.getenv('TEST_ENV')}")
    monkeypatch.setenv("TEST_ENV", "test")
    print(f"TEST_ENV: {os.getenv('TEST_ENV')}")

def test_monkeypatch_resets():
    print(f"TEST_ENV: {os.getenv('TEST_ENV')}")

This outputs:

TEST_ENV: None
TEST_ENV: test
TEST_ENV: None

You can see that the environment resets after the test using the monkeypatch fixture completes. This is the case with all monkeypatch usage, which makes it especially useful for tests that need to modify objects, dictionaries, and environment variables as setup.

In contrast, we can also modify the environment using the os package like so:

import os

def test_os_setenv():
    print(f"TEST_ENV: {os.getenv('TEST_ENV')}")
    os.environ["TEST_ENV"] = "test"
    print(f"TEST_ENV: {os.getenv('TEST_ENV')}")

def test_os_setenv_does_not_reset():
    print(f"TEST_ENV: {os.getenv('TEST_ENV')}")

Outputs:

TEST_ENV: test
TEST_ENV: test

Here, both tests have TEST_ENV set even though the second test never sets the environment variable itself. This means the change made by os.environ carries over between tests. monkeypatch is a safer alternative for testing because it resets after each test function completes.

You can find the whole list of pytest built-in fixtures here: https://docs.pytest.org/en/stable/reference/fixtures.html#built-in-fixtures

Moral of the story: when you need to do something in pytest, check to see if there's a pytest-provided alternative first. It can often make things much cleaner and easier to maintain.

find command finds things

Eric Chen — Wed, 15 Jul 2026 18:47:13 +0000

Recently I learned: find is a useful command to find files in your directories.

find folder1 folder2 folder3

This dumps every file and directory under those folders.

It also supports flags such as -name "*.txt" to find files matching a particular pattern. There are also filters for size, permissions, and last modified date.

I'm thinking this would be a great tool for sanity-testing code that creates nested directories (like a new Docker container's filesystem). This command will give me a full flat listing of the resulting tree (like a deeply nested ls command`).

The downside is of course it can dump a lot of output, but in sanity-testing scenarios, there shouldn't be that many files anyways.

Something interesting is that this command will take multiple folders before the flags. I'm used to thinking of programs where the arguments are all positionally ordered, so if you don't pass a flag it just assumes the next thing is a regular argument. In this case, find checks whether an argument looks like a flag (starts with -) before deciding whether to treat it as a path or as part of the expression. I wonder if this is a common pattern across other Linux commands. (Claude says find is special case, but I need to look more into this.)

DEV Community: Eric Chen

Pytest Built-in Fixtures

find command finds things