DEV Community: Nyakio Muriuki J

Pytest in Practice

Nyakio Muriuki J — Wed, 23 Sep 2026 20:31:53 +0000

I've been learning Python by building a video clipping CLI application, and along the way I've ended up learning a lot more than I expected.

Some of it was straightforward. Some of it made me stop and think, especially when I first started writing tests.

Things like:

How does pytest even know which functions are tests?
Why does everyone keep putting things in conftest.py?
When should I use a fixture?
What's the difference between patch and monkeypatch?
Why did my mock not work when I was sure I patched the right thing?
When should I mock something, and when should I just run the real thing?
What's the point of parametrization when I could just use a loop?
How do I debug one failing test without running the entire suite every time?

These are the kinds of things that can feel like arbitrary rules when you're first encountering them.

Once I understood the reasoning behind them, though, pytest started making a lot more sense.

So this isn't meant to be a complete pytest reference or an explanation of every feature pytest has. It's more like a collection of the things that finally "clicked" for me while testing a real Python project.

The examples are based on my video clipping CLI, so you'll see things like FFmpeg, video metadata, audio extraction, transcription, temporary files, external dependencies, and slow tests.

Hopefully, if you're also learning Python by building something rather than just following tutorials, some of these lessons save you a few of the "why does it work like that?" moments I had.

Installing pytest

If you're using uv, installing pytest and coverage support is straightforward:

uv add --dev pytest pytest-cov
uv run pytest --version

You now have everything needed to start writing and running tests.

Your First Test

A pytest test can be nothing more than a function:

# tests/core/test_video_inspector.py

from clipper.core.video_inspector import get_video_metadata


def test_get_video_metadata_returns_none_on_missing_file():
    result = get_video_metadata("does_not_exist.mp4")
    assert result is None

Run it with:

uv run pytest

That's it.

There is no base class, no registration, and no decorator required.

pytest finds the test because:

the file starts with test_
the function starts with test_

That naming convention is the mechanism.

How Does pytest Find Your Tests?

pytest automatically walks the current directory and its subdirectories looking for test files.

By default, it looks for files matching patterns such as:

test_*.py
*_test.py

Inside those files, it looks for functions matching:

test_*

and, inside classes whose names start with Test*, methods that also match test_*.

So this:

tests/
└── core/
    └── test_video_inspector.py

is enough for pytest to discover the file automatically. You don't need to register the test anywhere.

This is also why commands such as:

uv run pytest --cov=src

work without explicitly listing every test file. pytest's discovery mechanism does the work.

Assertions: Just Use `assert`

One of the nicest things about pytest is that you use Python's built-in assert.

def test_fps_math():
    assert round(29.970029970029969, 2) == 29.97

You don't need a collection of methods like:

assertEqual(...)
assertTrue(...)
assertFalse(...)
assertIn(...)

Instead, pytest rewrites assert statements when running tests so that failures contain useful information about what each side evaluated to. That makes a failed assertion much more informative than simply:

Assertion failed

Comparing Floats with `pytest.approx`

Don't compare floating-point calculations using exact equality.

Instead:

import pytest


def test_duration_seconds():
    assert 125.5 == pytest.approx(float("125.500001"))

Floating-point calculations rarely land exactly where you expect. This matters especially when dealing with things like frame rates, durations, timestamps, or calculations involving Fraction.

Without pytest.approx, you might end up writing this everywhere:

assert abs(actual - expected) < 0.001

pytest.approx gives you the tolerance without repeating that boilerplate.

`pytest.approx` Works with Nested Structures

pytest.approx isn't limited to individual numbers. You can use it when comparing nested structures:

def test_transcribe_matches_golden_output(
    sample_speech_path,
    sample_transcript,
):
    result = transcribe(str(sample_speech_path))

    assert result == pytest.approx(sample_transcript)

This is particularly useful for regression or "golden file" tests. Imagine a transcript like:

{
    "segments": [
        {
            "start": 0.123456,
            "end": 1.987654,
            "words": [
                {"word": "hello", "start": 0.123},
                {"word": "world", "start": 0.456},
            ],
        }
    ]
}

You don't want to write a loop comparing every timestamp manually. pytest.approx can recursively compare numeric values with tolerance while still using normal equality for strings and other values — so it's practical to compare an entire expected transcript while allowing for harmless floating-point differences.

Testing That an Error Is Actually Raised

When the expected behavior is for a function to raise an exception, use pytest.raises.

import pytest


def test_extract_audio_raises_on_bad_codec():
    with pytest.raises(ffmpeg.Error):
        extract_audio(
            "in.mp4",
            "out.wav",
            codec="not_a_real_codec",
        )

This test verifies two things:

The code raises an exception.
The exception is the expected type.

The test fails if the function doesn't raise anything. It also fails if it raises a different exception type. Both outcomes are useful information.

`pytest.raises` Only Works When the Exception Escapes

There's an important distinction here. Suppose your function catches its own exception:

def extract_audio(...):
    try:
        ...
    except ffmpeg.Error:
        logger.error(...)
        return None

The exception never reaches the caller. Therefore, this won't work:

with pytest.raises(ffmpeg.Error):
    extract_audio(...)

There's nothing left for pytest.raises to catch. Instead, test the function's actual contract:

result = extract_audio(...)

assert result is None

And, if logging is part of the behavior you care about, use caplog to verify that the expected error was logged.

A useful rule of thumb:

If the function returns None from its except block, test the return value rather than expecting an exception.

Parametrize: One Test, Many Inputs

Suppose you need to test several timestamp formats. You could write three tests:

def test_timestamp_one():
    ...


def test_timestamp_two():
    ...


def test_timestamp_three():
    ...

But the test logic is identical. That's exactly what pytest.mark.parametrize is for:

@pytest.mark.parametrize(
    "timestamp,expected_seconds",
    [
        ("00:00:01", 1.0),
        ("00:01:00", 60.0),
        ("01:00:00", 3600.0),
    ],
)
def test_validate_timestamp_parses_valid_formats(
    timestamp,
    expected_seconds,
):
    assert validate_timestamp(timestamp) == pytest.approx(expected_seconds)

Think of it like a form letter: the first argument names the blanks to fill in (timestamp, expected_seconds), and the second argument is a stack of filled-in versions. pytest prints one out and runs the test for each one:

test_validate_timestamp_parses_valid_formats[00:00:01-1.0]
test_validate_timestamp_parses_valid_formats[00:01:00-60.0]
test_validate_timestamp_parses_valid_formats[01:00:00-3600.0]

Each case can pass or fail independently.

Why independence matters

You could achieve something similar with a loop:

def test_timestamps():
    for timestamp, expected in cases:
        assert validate_timestamp(timestamp) == expected

But there's a major difference: a normal loop stops at the first failure. With parametrization, pytest runs every case. So one test run tells you exactly which inputs are broken instead of merely telling you:

test_timestamps failed

When should you use it?

The signal is simple:

If you're about to write several nearly identical test functions that differ only in their input values, consider parametrize.

It works just as well for valid inputs as it does for malformed or invalid ones.

Grouping Tests in a Class

pytest supports test classes:

class TestGetVideoMetadata:
    def test_returns_none_for_missing_file(self):
        assert get_video_metadata("missing.mp4") is None

    def test_has_audio_true_when_audio_stream_present(self):
        ...

But classes aren't mandatory. Use them when they provide something useful, such as:

shared setup
fixtures scoped to the group
applying a marker to multiple tests

Don't use a class purely because it feels more organized. A well-named test file already provides plenty of organization.

An important detail about test classes

Each test method gets a fresh instance of the class. So this:

class TestSomething:
    def test_one(self):
        self.value = 1

    def test_two(self):
        assert self.value == 1

is not valid. test_two doesn't receive the instance used by test_one. That's intentional — tests should be isolated from one another. Depending on mutable state from another test creates order-dependent and difficult-to-debug failures.

Fixtures

Fixtures are one of pytest's most useful features. A fixture is a function that provides something a test needs — think of it like an ingredient a recipe asks for by name. You don't prep it inside the recipe itself; you just say "I need sample_video_path" and pytest hands it to you already made.

# tests/conftest.py

import pytest
from pathlib import Path


@pytest.fixture
def sample_video_path() -> Path:
    return Path(__file__).parent / "fixtures" / "sample.mp4"

A test can then request it simply by putting the fixture name in its parameters:

# tests/core/test_video_inspector.py

def test_metadata_against_real_file(sample_video_path):
    result = get_video_metadata(str(sample_video_path))

    assert result is not None

pytest sees sample_video_path in the test signature, finds the fixture with that name, runs it, and passes the result to the test. No import is required.

Why `conftest.py` Matters

conftest.py is automatically discovered by pytest. Fixtures defined there are available to test files in the same directory and its subdirectories — it works like a shared pantry that any test file in that part of the tree can pull from without asking for a delivery.

For example:

tests/
├── conftest.py
├── core/
│   └── test_video_inspector.py
└── api/
    └── test_transcription.py

A fixture defined in tests/conftest.py is available to both tests/core/ and tests/api/.

You can also have a more specific conftest.py deeper in the tree:

tests/
├── conftest.py
└── core/
    ├── conftest.py
    └── test_video_inspector.py

The deeper fixture configuration can then be used specifically by that subtree. A useful convention is: root conftest.py for shared fixtures, nested conftest.py files for fixtures that are genuinely local to a particular test area.

Fixture Scope

Fixtures don't necessarily have to run for every test. You can control their lifetime:

@pytest.fixture(scope="function")  # default
@pytest.fixture(scope="module")    # once per test file
@pytest.fixture(scope="session")   # once per entire test run

The default is scope="function", which means a fresh fixture is created for every test. Prefer the default unless there is a good reason to reuse the fixture.

A broader scope can make sense when setup is genuinely expensive and safe to share. For example, generating a synthetic sample video once per session may be much cheaper than generating it once for every test.

Built-in Fixtures Worth Knowing

pytest provides several useful fixtures out of the box.

`tmp_path`

Provides a unique temporary directory for each test. Great for anything that needs to write files.

`caplog`

Captures logging output. Useful when you want to verify that something logged an error or warning.

`capsys`

Captures stdout and stderr. Useful for testing CLI output.

`monkeypatch`

Temporarily changes attributes, environment variables, dictionary entries, and other values. pytest automatically restores the changes after the test.

You can inspect available fixtures with:

uv run pytest --fixtures

`tmp_path` in Practice

Suppose you want to verify that audio extraction creates an actual file:

def test_extract_audio_writes_real_file(
    sample_video_path,
    tmp_path,
):
    output_path = tmp_path / "output.wav"

    result = extract_audio(
        str(sample_video_path),
        str(output_path),
    )

    assert result == str(output_path)
    assert output_path.exists()

This is an integration-style test. It actually runs FFmpeg and checks that a real file was created. But because tmp_path is temporary, the test doesn't leave generated files scattered around your project — pytest creates the directory and handles its cleanup.

Mocking: Two Tools, Different Jobs

Python gives you unittest.mock. pytest gives you monkeypatch. They overlap, but each one shines in a different situation.

`unittest.mock.patch`

Use patch when you want a more capable mock, particularly when you need to inspect how something was called.

from unittest.mock import patch


def test_metadata_no_audio():
    fake_probe = {
        "format": {
            "filename": "silent.mp4",
            "duration": "10.0",
        },
        "streams": [
            {
                "codec_type": "video",
                "r_frame_rate": "25/1",
            },
        ],
    }

    with patch(
        "clipper.core.video_inspector.ffmpeg.probe",
        return_value=fake_probe,
    ):
        result = get_video_metadata("silent.mp4")

    assert result["has_audio"] is False

patch temporarily replaces the target with a mock. It is particularly useful when you want to assert things like:

mock_input.assert_called_once_with("in.mp4")

`monkeypatch`

monkeypatch is pytest's own fixture. It's particularly convenient for simple temporary substitutions.

def test_uses_default_bitrate_env_var(monkeypatch):
    monkeypatch.setenv(
        "CLIPPER_DEFAULT_BITRATE",
        "256k",
    )

    assert get_default_bitrate() == "256k"

There's no context manager and no manual cleanup — pytest automatically restores the environment variable after the test. You can also replace attributes with monkeypatch.setattr(...) or dictionary entries with monkeypatch.setitem(...).

`patch` vs `monkeypatch`: A Practical Mental Model

Imagine your code is a toy robot and you want to test what happens when one of its components behaves differently. You don't want to actually break the component — you just want to temporarily pretend that it behaves differently.

monkeypatch is like putting a temporary sticky note over the component: "For this test, pretend this value is different." pytest removes the note when the test finishes.

patch is another version of the same idea, but with a much more powerful mock object behind it. patch can easily track call count, arguments, return values, exceptions, and chained calls.

Both clean themselves up reliably when used correctly. With patch, the common form in this project is:

with patch(...):
    ...

The mock is restored automatically when the block ends, even if the test fails.

Which One Should You Use?

A practical rule:

Need	Use
Assert how something was called	`patch`
Check call count or exact arguments	`patch`
Mock a chained/fluent API	`patch`
Replace an environment variable	`monkeypatch`
Temporarily change one attribute	`monkeypatch.setattr(...)`
Temporarily change a dictionary entry	`monkeypatch.setitem(...)`
Replace an external dependency and inspect the mock	`patch`

The important thing isn't to memorize a strict rule. It's to recognize the distinction:

If you need to inspect how the dependency was used, patch is usually the natural choice. If you just need to temporarily replace a value or attribute, monkeypatch is often simpler.

`side_effect`: Make a Mock Fail

Mocks aren't only useful for returning fake successful results. They can also simulate failures.

return_value means "always return this." side_effect means "raise this exception instead."

with patch(
    "clipper.core.video_inspector.ffmpeg.probe",
    side_effect=ffmpeg.Error(
        cmd="ffprobe",
        stdout=b"",
        stderr=b"bad file",
    ),
):
    result = get_video_metadata("bad.mp4")

This lets you exercise failure paths without needing to create a genuinely broken video file.

Mock the Boundary, Not Your Own Logic

This is probably the most important mocking rule in the entire guide:

Mock the boundary, not the logic you're trying to test.

Suppose your code does this:

probe = ffmpeg.probe(path)

The interesting logic is what your application does with the result. So mock ffmpeg.probe and provide realistic fake data — don't mock the parsing logic itself. A test that mocks everything, including the thing you're trying to test, can end up proving nothing more than: "my mocks returned what I told them to return."

Put another way — you're testing your recipe, not reinventing the oven. External boundaries are good mocking candidates:

FFmpeg
HTTP APIs
databases
filesystem operations
cloud services
external processes

Your own business logic is usually what you want to execute for real.

The Most Common Mocking Mistake: Patching the Wrong Path

This catches a lot of people. Suppose your module contains:

# video_inspector.py

import ffmpeg


def get_video_metadata(path):
    return ffmpeg.probe(path)

You might think you should patch ffmpeg.probe. But that's not necessarily the correct target — the code under test looks up ffmpeg in its own module namespace. Therefore, patch where the name is looked up:

patch(
    "clipper.core.video_inspector.ffmpeg.probe"
)

The general rule is:

Patch where the object is looked up, not where it was originally defined.

If you patch the wrong path, the real dependency may still run. That can make a test unexpectedly hit FFmpeg, the network, a database, or some other external system.

Mocking a Chained Call

Some APIs aren't a single function call. For example, ffmpeg-python can use a fluent chain:

ffmpeg.input(...).output(...).overwrite_output().run(...)

Mocking that requires walking the chain. MagicMock automatically creates mocks for attributes you access, so mock_input.return_value represents the result of ffmpeg.input(...), .output.return_value represents the next link in the chain, and so on until you reach .run — the actual operation you want to make fail.

def test_extract_audio_sad_path(caplog):
    fake_error = ffmpeg.Error(
        cmd="ffmpeg",
        stdout=b"",
        stderr=b"encoding failed",
    )

    with patch(
        "clipper.core.video_inspector.ffmpeg.input"
    ) as mock_input:
        mock_run = (
            mock_input
            .return_value
            .output
            .return_value
            .overwrite_output
            .return_value
            .run
        )
        mock_run.side_effect = fake_error

        result = extract_audio(
            "in.mp4",
            "out.wav",
        )

    assert result is None
    assert "error" in caplog.text.lower()

Walking the chain into its own variable (mock_run) before setting side_effect keeps the assignment itself simple and unambiguous — trying to set an attribute in the middle of a long parenthesized chain is a common source of syntax mistakes.

Organizing Your Test Files

A simple and predictable test layout goes a long way. If your source looks like:

src/
└── clipper/
    └── core/
        └── video_inspector.py

mirror it under tests/:

tests/
└── core/
    └── test_video_inspector.py

This makes it immediately obvious where the tests for a source module live.

Keep `tests/` Outside `src/`

Use:

project/
├── src/
├── tests/
└── pyproject.toml

rather than:

src/
├── clipper/
└── tests/

Keeping tests outside the package helps avoid accidentally shipping them with your built distribution and keeps the distinction between application code and test code clear.

You Usually Don't Need `init.py`

pytest doesn't require your test directories to be Python packages. So this is perfectly fine:

tests/
├── core/
│   └── test_video_inspector.py
└── api/
    └── test_transcription.py

No __init__.py required. There can be edge cases where you intentionally want package semantics, but don't add __init__.py to test directories just because you think pytest requires it. It doesn't.

Keep Fixtures Separate from Test Code

tests/
├── conftest.py
├── fixtures/
│   └── sample.mp4
└── core/
    └── test_video_inspector.py

This makes the distinction obvious: test_*.py contains test logic, fixtures/ contains test data.

Mark Slow and External Tests

Not every test costs the same amount to run. A test that calls real FFmpeg is different from a test that checks a pure Python function.

You can mark integration tests:

@pytest.mark.integration
def test_extract_audio_against_real_file(...):
    ...

Then register the marker in pyproject.toml:

[tool.pytest.ini_options]
markers = [
    "integration: calls real ffmpeg/ffprobe against a fixture file",
]

Now you can run the fast suite without integration tests:

pytest -m "not integration"

And run everything with:

pytest

This gives you a useful distinction between fast unit tests and slower integration tests.

Debugging pytest Without Sprinkling `print()` Everywhere

pytest captures output by default. That can be surprising when you're debugging — a print(result) that produces nothing on screen. Here are the options you'll reach for most often.

`-s`: Show stdout/stderr

uv run pytest -s

This disables output capturing, so your print() statements become visible. It's useful, although there are usually better debugging tools than adding prints everywhere.

`-k`: Run Tests by Name

If you're working on audio extraction, there's no reason to run 200 unrelated tests.

uv run pytest -k "extract_audio"

pytest runs tests whose names match the expression. This is one of the most useful options during active development.

`-x`: Stop at the First Failure

uv run pytest -x

Instead of getting a wall of failures, pytest stops after the first one. This is particularly useful when fixing a cascading failure.

`--pdb`: Drop Into the Debugger

uv run pytest --pdb

When a test fails, pytest drops you into an interactive debugger at the point of failure. Inside the debugger, you can inspect variables and control execution — c continues, q quits. This can be much faster than trying to predict where a bug is before running the test.

`-vv`: More Verbose Output

uv run pytest -vv

Useful when assertions involve large dictionaries, long strings, or parametrized tests and you want more detail in the output.

`--lf`: Run Only the Last Failures

uv run pytest --lf

--lf means "last failed." It reruns tests that failed during the previous run instead of running the entire suite. This is particularly useful when you're fixing several failures one by one.

A Practical Debugging Command

These options can be combined:

uv run pytest -k "extract_audio" -x --pdb

This means: run only tests matching extract_audio, stop at the first failure, and open the debugger at the failure. That's a very practical development loop.

Running a Specific Test

pytest doesn't natively use line numbers to select a test. This isn't standard pytest test selection:

pytest test_file.py:29

Instead, select by node ID:

pytest tests/core/test_video_inspector.py::test_metadata_no_audio

Or use -k:

pytest -k "metadata_no_audio"

Editors such as VS Code and PyCharm can provide "run this test" buttons. They translate your selection into pytest's name-based test selection behind the scenes. There are plugins that provide literal line-number selection, but you generally don't need one.

Quickly Inspecting a Return Value

Sometimes you just want to see what a function actually returned. One quick technique is to deliberately make an assertion fail:

def test_scratch(sample_video_path):
    result = get_video_metadata(str(sample_video_path))

    assert result == {}

If {} isn't the actual result, pytest's failure output will show you the value. Delete the temporary test afterward.

Another option is:

uv run pytest --showlocals

or the shorthand -l, which shows local variables when a test fails.

Dealing with Slow Tests

Don't guess which tests are slow. Measure them.

uv run pytest --durations=10

This reports the ten slowest tests after the run. You may discover that one or two tests account for most of the delay. Optimizing everything before measuring can waste the very time you're trying to save.

Mark Slow Tests

Tests that load a real model or perform real inference are good candidates for a slow marker:

@pytest.mark.slow
def test_transcribe_real_audio_produces_valid_shape(
    sample_speech_path,
):
    ...

[tool.pytest.ini_options]
markers = [
    "integration: calls real ffmpeg/ffprobe against a fixture file",
    "slow: tests that load a real model or run real transcription",
]

Then your normal development loop can skip them:

pytest -m "not slow"

And your complete suite can still run with pytest.

Caching Can Already Solve Some Performance Problems

Suppose your application loads a model once at module level, and subsequent calls reuse it. Then only the first test that needs the model may pay the expensive loading cost — the others can reuse the already-loaded instance.

You can verify whether this is actually happening with uv run pytest --durations=10. If the first model-related test is slow and subsequent tests are much faster, your existing caching may already be doing the job. If every test is slow, something may be reloading the model when it shouldn't. Measure first.

Parallelizing the Suite

If the entire suite is slow, rather than just a handful of expensive tests, parallel execution may help.

uv add --dev pytest-xdist
uv run pytest -n auto

-n auto lets xdist determine a useful number of workers. But don't reach for parallelization automatically — for many projects, simply excluding slow tests during development (pytest -m "not slow") is enough.

Coverage Is a Flashlight, Not a Scoreboard

Coverage is useful. It tells you which lines of code weren't exercised by your tests.

uv run pytest --cov=src

This can help you find code paths you haven't thought about. But coverage doesn't tell you whether your tests are good. You can achieve 100% coverage with tests that assert almost nothing meaningful:

def test_everything():
    my_function()

The code executed. Coverage increases. But the test may tell you almost nothing about whether the behavior is correct. So treat coverage as a flashlight — use it to illuminate parts of the code you haven't tested. Don't treat it as a scoreboard you have to maximize.

A Simple Checklist for Every New Test

When adding tests for a new function or feature, ask:

1. What's the happy path?

What should happen when everything is valid?

2. What's at least one edge case?

Consider: empty input, missing fields, boundary values, unexpected but valid combinations.

3. What's the failure mode?

What should happen when input is invalid, an external dependency fails, a file doesn't exist, or an API returns an unexpected result?

4. What should be mocked?

Usually mock things that are external, slow, non-deterministic, or side-effecting. But let your own logic run for real.

5. Is the test asking one question?

If the test name contains the word "and," that's sometimes a sign that you're testing two behaviors at once. A test should ideally answer one clear question.

The Mental Model I Ended Up With

pytest can look like a large collection of features when you're first learning it. But after working with it for a while, I found that most of what I actually needed came down to a few ideas.

Tests are ordinary Python functions. pytest discovers them through naming conventions.

Assertions are ordinary Python assert statements. pytest makes their failures informative.

Fixtures provide reusable things that tests need. conftest.py makes shared fixtures available without imports.

Parametrization lets you run the same test logic against multiple inputs.

Mocks let you replace boundaries you don't want to exercise for real. Things like FFmpeg, APIs, databases, and other external systems are often good candidates — while the logic you're actually testing should usually run normally.

Markers let you separate tests by purpose or cost. And the debugging tools make it much easier to figure out why something failed without resorting to print() everywhere.

Most importantly, I stopped thinking of testing as "how do I get my coverage number up?" and started thinking more in terms of "what question am I trying to answer with this test?" For me, that shift made pytest much easier to understand.

The syntax is the easy part. The useful part is learning what behavior is worth testing, what should be isolated, what should run for real, and how to make a failure tell you something useful.

Learning `just`: A Practical Task Runner

Nyakio Muriuki J — Thu, 03 Sep 2026 13:30:33 +0000

I've been learning just recently.

I came across it while setting up a Python project and looking for a simple way to collect all the commands I use during development.

This started with something I got used to in Elixir.

One of the things I really like about Elixir projects is that you can put the common development tasks behind simple commands/aliases:

mix format
mix test
mix ci

You don't have to remember every command that runs underneath. The project gives you a small set of commands and you use those.

I wanted something similar for a Python project.

For example, instead of remembering all the different checks I need to run, I wanted to be able to do this:

just ci

and let the project take care of the rest.

My first thought was Make

Make was the obvious choice.

I've used Make a lot, and it works. It's installed almost everywhere, most developers have seen a Makefile before, and there is a huge amount of existing knowledge around it.

So I started there.

The setup was pretty small:

format:
    uv run ruff format --check .

lint:
    uv run ruff check .

typecheck:
    uv run mypy src/

test:
    uv run pytest --cov=src --cov-report=term-missing

ci: format lint typecheck test

That gave me exactly what I wanted.

I could run:

make format
make lint
make typecheck
make test
make ci

Nothing complicated.

But while doing this, I kept seeing just mentioned in newer projects.

That made me curious.

Not because I thought Make was bad. I still use it a lot, and I have no problem reaching for it.

I just wondered what just was doing differently.

Was it basically Make with different syntax? Was it easier to use? Did it solve some of the small annoyances that come with Make?

So I decided to rebuild the same thing in just and see.

The `just` version

The nice thing was that I didn't have to change any of the actual commands.

I just changed the wrapper around them:

format:
    uv run ruff format --check .

lint:
    uv run ruff check .

typecheck:
    uv run mypy src/

test:
    uv run pytest --cov=src --cov-report=term-missing

ci: format lint typecheck test

That's pretty much the whole file.

Now I can run:

just format
just lint
just typecheck
just test

Or everything with:

just ci

The ci recipe depends on the other four recipes, so just ci runs them in order and stops when one fails.

For what I was trying to do, it felt very familiar.

And that was probably the first thing I noticed. I didn't really have to learn a new way of thinking about the problem.

A few things I liked about `just`

The basic syntax is very similar to Make.

You have a recipe, optional dependencies, and then the commands to run:

recipe_name: dependency1 dependency2
    command to run

But there are a few differences that make sense when you're using it mainly as a task runner.

No `.PHONY`

With Make, you often have something like:

.PHONY: format lint typecheck test ci

That's because Make is also a build system and cares about files and timestamps.

For these development commands, I don't really need that behaviour.

just doesn't use file timestamps to decide whether a recipe needs to run, so there is no .PHONY declaration to maintain.

No tab problem

Then there is the classic Make issue where a command needs to be indented with a tab.

I've definitely lost time to that one.

With just, you don't have that same tab requirement. You use normal indentation.

It might seem like a small thing, but I like small improvements in tools I use.

`just --list`

This was another nice surprise.

You can run:

just --list

and get a list of the recipes available in the project.

You can add comments above recipes too:

# Format check
format:
    uv run ruff format --check .

# Run tests
test:
    uv run pytest --cov=src --cov-report=term-missing

Those comments can then show up when listing the recipes.

You can also make just itself show the list:

default:
    @just --list

So a developer can clone the project and run:

just

to see what is available.

I like that because the task runner becomes a small piece of documentation.

But is `just` actually better than Make?

I'm not sure that's the right question.

Make is still a great choice in plenty of situations.

If I'm working on a project that already has a Makefile, I'm not going to suggest replacing it with just just because just is newer.

And if I'm writing something that needs to work in an environment where Make is already installed, that is a pretty good reason to use Make.

The thing I found interesting about just is that it feels more focused on the thing I was actually trying to do.

I wasn't building anything based on file timestamps.

I just wanted names for common commands and a way to combine them.

For that use case, just is pretty nice.

But it also comes with a trade-off. Unlike Make, you probably have to install it first.

So the comparison for me looks something like this:

	Make	just
Already installed	Often	Usually not
Task runner	Yes	Yes
Build system	Yes	No
`.PHONY`	Often needed	Not needed
Tab requirement	Yes	No
Task listing	DIY	Built in
Cross-platform	Possible	Designed for it

Neither one wins across the board.

Make has ubiquity.

just has a nice developer experience.

Which one makes more sense depends on the project.

There are other options too

Once I started looking into this, I found quite a few other tools doing roughly the same thing.

Task (go-task) was one I came across. It uses a YAML Taskfile.yml and has some useful features around variables and templating.

For Python, poethepoet was another interesting option. It lets you put tasks in pyproject.toml, which can be nice if you don't want another configuration file.

And if you're working in Node, npm scripts already give you a similar setup through package.json.

They all solve a similar problem.

You have a bunch of commands that developers need to run, and you give those commands names so people don't have to remember all the details.

The differences are mostly around syntax, ecosystem, and how much functionality you want.

So, am I switching to `just`?

For everything? No.

I'm still going to use Make.

If I open a project and there is a Makefile, I'll use it. If I'm working on infrastructure where Make is already expected, I'll probably use it there too.

But for projects I start myself, I can see myself reaching for just.

The thing I liked most was how little there was to learn.

My existing commands stayed exactly the same. I just put a small, readable interface around them.

That brought me back to why I started looking at this in the first place.

In Elixir, I'm used to having commands like:

mix ci

that give the project a simple interface for common development tasks.

With Python, I found myself wanting the same thing.

Make was one way to do it.

just is another.

I'm glad I spent the time learning it. Not because it replaced Make, but because now I know another tool that fits this particular problem really well.

And sometimes that's enough of a reason to try something new.

DEV Community: Nyakio Muriuki J

Pytest in Practice

Installing pytest

Your First Test

How Does pytest Find Your Tests?

Assertions: Just Use assert

Comparing Floats with pytest.approx

pytest.approx Works with Nested Structures

Testing That an Error Is Actually Raised

pytest.raises Only Works When the Exception Escapes

Parametrize: One Test, Many Inputs

Why independence matters

When should you use it?

Grouping Tests in a Class

An important detail about test classes

Fixtures

Why conftest.py Matters

Fixture Scope

Built-in Fixtures Worth Knowing

tmp_path

caplog

capsys

monkeypatch

tmp_path in Practice

Mocking: Two Tools, Different Jobs

unittest.mock.patch

monkeypatch

patch vs monkeypatch: A Practical Mental Model

Which One Should You Use?

side_effect: Make a Mock Fail

Mock the Boundary, Not Your Own Logic

The Most Common Mocking Mistake: Patching the Wrong Path

Mocking a Chained Call

Organizing Your Test Files

Keep tests/ Outside src/

You Usually Don't Need __init__.py

Keep Fixtures Separate from Test Code

Mark Slow and External Tests

Debugging pytest Without Sprinkling print() Everywhere

-s: Show stdout/stderr

-k: Run Tests by Name

-x: Stop at the First Failure

--pdb: Drop Into the Debugger

-vv: More Verbose Output

--lf: Run Only the Last Failures

A Practical Debugging Command

Running a Specific Test

Quickly Inspecting a Return Value

Dealing with Slow Tests

Mark Slow Tests

Caching Can Already Solve Some Performance Problems

Parallelizing the Suite

Coverage Is a Flashlight, Not a Scoreboard

A Simple Checklist for Every New Test

1. What's the happy path?

2. What's at least one edge case?

3. What's the failure mode?

4. What should be mocked?

5. Is the test asking one question?

The Mental Model I Ended Up With

Learning `just`: A Practical Task Runner

My first thought was Make

The just version

A few things I liked about just

No .PHONY

No tab problem

just --list

But is just actually better than Make?

There are other options too

So, am I switching to just?

Assertions: Just Use `assert`

Comparing Floats with `pytest.approx`

`pytest.approx` Works with Nested Structures

`pytest.raises` Only Works When the Exception Escapes

Why `conftest.py` Matters

`tmp_path`

`caplog`

`capsys`

`monkeypatch`

`tmp_path` in Practice

`unittest.mock.patch`

`monkeypatch`

`patch` vs `monkeypatch`: A Practical Mental Model

`side_effect`: Make a Mock Fail

Keep `tests/` Outside `src/`

You Usually Don't Need `init.py`

Debugging pytest Without Sprinkling `print()` Everywhere

`-s`: Show stdout/stderr

`-k`: Run Tests by Name

`-x`: Stop at the First Failure

`--pdb`: Drop Into the Debugger

`-vv`: More Verbose Output

`--lf`: Run Only the Last Failures

The `just` version

A few things I liked about `just`

No `.PHONY`

`just --list`

But is `just` actually better than Make?

So, am I switching to `just`?