inline-snapshot writes expected values into your test source

The expectation lives next to the assertion, not in a side file

The problem is the classic one of golden master testing, or approval testing, and the usual answer is a directory of snapshot files that a test runner compares against. The cost of that answer is that the expectation and the assertion are in different places, and reading a test means jumping between two files. inline-snapshot takes the other route, described in the project metadata as a golden master, snapshot and approval testing library which puts the values right into your source code. The semantics are deliberately plain, with snapshot(x) mirroring x for easy understanding, and the mechanism is a pytest plugin that rewrites the test file during the run. The intended user is a Python developer whose expected values are natural to write as code, and who would rather see the literal in the assertion than in a separate fixture. It comes from PyPI:

pip install inline-snapshot

You write an empty snapshot, then let the run fill it in

The workflow is the part that makes the library usable. You replace the value you want to compare with a call to snapshot(), leaving it empty, and the first run records the correct value. The example in the README is a single line, an assertion that a multiplication equals snapshot():

from inline_snapshot import snapshot


def test_something():
    assert 1548 * 18489 == snapshot()

``` After running the tests the recorded value appears in the file as a literal inside the call. The command that does the recording is pytest with the review flag:

$ pytest --inline-snapshot=review

and the README notes that no CLI arguments are required because you get a report where you can review the snapshot changes when you run pytest, with the caveat that this automatic report only works for CPython newer than 3.11 and older versions need the flag spelled out. So the interaction is a report and a review, not a silent write.

Comparison operators, not just equality

The comparison support is broader than the equality case most snapshot libraries cover, and it is the part that makes the plugin usable in real code. The README lists support for x == snapshot(...), x <= snapshot(...), x in snapshot(...), and snapshot(...)[key], each with its own documentation page. That last one matters more than it looks, because it lets a snapshot hold a structure you then index into, so a single recorded value can drive several assertions. The comparison operators are useful in the other direction too: instead of writing a range by hand, you can record the boundary value and compare against it, and the recorded value stays in sync with the code. A snapshot can also contain other snapshots, so a nested structure is recorded in one piece rather than assembled from several.

snapshot_arg records a function's arguments as a snapshot

There is a second entry point for a different job, snapshot_arg(), which converts the arguments of a function into snapshots. The README example wraps a helper that runs a Python command as a subprocess and captures the output, then asserts that the decoded stdout and stderr equal snapshot_arg of the expected values, so the recorded expectations are the actual output of the command rather than a hand-written string.

import subprocess as sp
import sys
from inline_snapshot import snapshot_arg


def run_python(cmd, stdout="", stderr=""):
    result = sp.run([sys.executable, "-c", cmd], capture_output=True)
    assert result.stdout.decode() == snapshot_arg(stdout)
    assert result.stderr.decode() == snapshot_arg(stderr)

That is a meaningful difference from the usual snapshot approach, because for anything that talks to a subprocess the expected value is often only knowable by running it. The feature is described in the README as integration into normal functions, and the second example in the README uses it for a command that succeeds and one that raises, so both streams are captured.

External files, outsource and dirty-equals for the awkward cases

Three features cover the cases where a literal in the source is the wrong shape. The first is external storage, where a snapshot can point at a file by an identifier such as external("uuid:eb1167b3-67a9-4378-bc65-c1e582e2e662.json"), with support for custom file formats, which is how you keep a large blob out of the test file. The second is outsource, used in the README example for a large multi-line string, which keeps the noise out of the source while still recording the value, as this excerpt shows:

from inline_snapshot import external, outsource, snapshot


def test_something():
    for number in range(5):
        # testing for numeric limits
        assert number <= snapshot()
        assert number >= snapshot()

    for c in "hello world":
        # test if something is part of a set
        assert c in snapshot()

The third is fuzzy matching through dirty-equals, which is incorporated for flexible comparisons within snapshots, so a snapshot can hold a matcher rather than a literal when the exact value is not the point of the test. The README also notes that snapshots can contain non-constant values, and that code generation can be customised through a plugin hook.

Formatting is kept in line with Black or your own formatter

Because the plugin rewrites your source files, the formatting of what it writes is not a cosmetic detail, and the README treats it as a feature. Formatting consistency is retained with Black formatting or a custom format-command, configured in the documentation under configuration. There is a Black extra in the package metadata for exactly that integration. The practical consequence for a team is that the plugin is a source rewriter, so it belongs in the same category of tool as a formatter, and a project that runs formatters in CI will see inline-snapshot's output pass through them. The formatting configuration is also the escape hatch for a project that does not use Black, since the format-command setting points at whatever formatter the project already runs.

A pytest plugin, so the flags are pytest flags

inline-snapshot is a pytest plugin rather than a standalone runner, and the README describes it as integrated with pytest for testing. That has an upside and a downside. The upside is that there is no separate command to learn, since the review report comes out of a normal pytest run and the recording mode is a pytest option. The downside is that the enhanced control flags for choosing which snapshots to change are pytest flags, and the plugin also needs a compatible pytest to work at all. The package metadata lists pytest as a runtime dependency at 8.3.4 or newer, alongside asttokens and executing, which are the two libraries that make it possible to find the exact source location of the call and rewrite that line, rich for the report output, tomli for Python older than 3.11, and typing-extensions. Python 3.9 or newer is required.

Small project, active release line, MIT licensed

The repository is small and conventional, with src/ holding the package, tests/ and testing/ holding the suite, docs/ with a mkdocs configuration, benchmarks/ driven by an asv configuration, a changelog.d/ directory for the changelog fragments, and a conftest.py at the root. There is a .inline-snapshot/ directory, which is where the plugin keeps its own configuration, and an asv.conf.json for the performance benchmark suite, plus a test-repos.json and a scripts/ directory. The version is 0.36.1, tagged on 2026-10-12, with 0.36.0 on 2026-10-02 and 0.35.4 on 2026-08-11, and the last push to the repository was on 2026-10-18, so the release line is moving quickly. The package is MIT licensed, the classifiers call it a beta, and the supported Python versions run from 3.9 to 3.14 on both CPython and PyPy. The author also maintains a Discord for the project and asks for feedback on how the advanced snapshot features are used.

Editorial conclusion

inline-snapshot suits a Python team that has outgrown hand-written expected values but finds separate snapshot files awkward to review, and it suits codebases where the expected value is naturally readable as Python, a dict or a literal. It does not suit a project that wants expectations in a separate artefact, for example because the test source is generated or the expectations must be shared between languages, and it should be treated carefully in a repository where reformatting your own files on every run is unwelcome. Before adopting, check the Python version, since the review mode needs CPython newer than 3.11 and older versions need the --inline-snapshot=review flag, and note that the last push to the repository was on 2026-10-18 with the newest tagged release v0.36.1 from 2026-10-12.

Frequently asked questions

Official sources

1. 15r10nk/inline-snapshot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases