Skip to main content

actions pypi womm

pytest-structlog

Structured logging assertions. pytest + structlog = pytest-structlog.

pytest structlog

Installation:

$ pip install pytest-structlog

Usage:

The fixture name is log. It has two attributes of interest: log.events is a list of events from captured log calls, and log.has is a helper function for asserting a single event was logged within the expected context.

Suppose you have some library module, your_lib, which is using structlog:

# your_lib.py
from structlog import get_logger

logger = get_logger()

def spline_reticulator():
    logger.info("reticulating splines")
    for i in range(3):
        logger.debug("processing", spline=i)
    logger.info("reticulated splines", n_splines=3)

Then your test suite might use assertions such as shown below:

# test_your_lib.py
from pytest_structlog import StructuredLogCapture

from your_lib import spline_reticulator


def test_spline_reticulator(log: StructuredLogCapture):
    assert len(log.events) == 0
    spline_reticulator()
    assert len(log.events) == 5

    # can assert on the event only
    assert log.has("reticulating splines")

    # can assert with subcontext
    assert log.has("reticulated splines")
    assert log.has("reticulated splines", n_splines=3)
    assert log.has("reticulated splines", n_splines=3, level="info")

    # but not incorrect context
    assert not log.has("reticulated splines", n_splines=42)
    assert not log.has("reticulated splines", key="bogus")

    # can assert with the event dicts directly
    assert log.events == [
        {"event": "reticulating splines", "level": "info"},
        {"event": "processing", "level": "debug", "spline": 0},
        {"event": "processing", "level": "debug", "spline": 1},
        {"event": "processing", "level": "debug", "spline": 2},
        {"event": "reticulated splines", "level": "info", "n_splines": 3},
    ]

    # can use friendly factory methods for the events to assert on
    assert log.events == [
        log.info("reticulating splines"),
        log.debug("processing", spline=0),
        log.debug("processing", spline=1),
        log.debug("processing", spline=2),
        log.info("reticulated splines", n_splines=3),
    ]

    # can use membership to check for a single event's data
    assert {"event": "reticulating splines", "level": "info"} in log.events

    # can use >= to specify only the events you're interested in
    assert log.events >= [
        {"event": "processing", "level": "debug", "spline": 0},
        {"event": "processing", "level": "debug", "spline": 2},
    ]

    # or put the comparison the other way around if you prefer
    assert [
        {"event": "processing", "level": "debug", "spline": 0},
        {"event": "processing", "level": "debug", "spline": 2},
    ] <= log.events

    # note: comparisons are order sensitive!
    assert not [
        {"event": "processing", "level": "debug", "spline": 2},
        {"event": "processing", "level": "debug", "spline": 0},
    ] <= log.events

    # count of events
    assert log.count("processing") == 3

Advanced configuration

By default, pytest-structlog attempts to nerf any pre-existing structlog configuration and set up a list of processors suitable for testing purposes. Sometimes more control over this setup may be desired, for example if the code under test uses custom processors which should be kept even during testing.

For these purposes, the plugin provides options to override the testing processors:

$ pytest --help | grep structlog --after=2
pytest-structlog:
  --structlog-keep=PROCESSOR_NAME
                        Processors to keep if configured (may be specified
                        multiple times).
  --structlog-evict=PROCESSOR_NAME
                        Processors to evict if configured (may be specified
                        multiple times).
...
  structlog_keep (args):
                        Processors to keep if configured (list of names)
  structlog_evict (args):
                        Processors to evict if configured (list of names)

Indicate that some specific processors should be kept during testing with:

pytest --structlog-keep my_processor1 --structlog-keep MyProcessor2

Or write this directly in config files, e.g. in pyproject.toml:

[tool.pytest.ini_options]
structlog_keep = ["my_processor1", "MyProcessor2"]

Sometimes, instead of listing processors to keep, it may be more convenient to list which processors to exclude during testing. In this case you may specify an eviction list:

[tool.pytest.ini_options]
structlog_evict = ["TimeStamper", "JSONRender"]

You may only use "keep" or "evict" mode. It is an error to specify both.

For complete control over which processors should be used in testing, the best way would be to add a structlog.configure() call directly in your conftest.py file and use --structlog-explicit (or set structlog_explicit = true) when running pytest to disable automatic processors selection entirely.

Using pytest -v or pytest -vv you can see more details about which processors pytest-structlog has included or excluded during the test startup. The reporting of pytest-structlog's own settings can also be explicitly enabled/disabled independently of verbosity level by specifying --structlog-settings-report always/never (cmdline) or structlog_settings_report (ini).

Metadata

Release files for pytest-structlog 1.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for pytest-structlog 1.2
File Size Uploaded Provenance Actions
pytest_structlog-1.2.tar.gz 13.3 kB Without provenance Details for pytest_structlog-1.2.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for pytest-structlog 1.2
File Interpreter ABI Platform Actions
pytest_structlog-1.2-py3-none-any.whl Python 3 none any Details for pytest_structlog-1.2-py3-none-any.whl

Total release size: 21.9 kB

Release files / pytest_structlog-1.2.tar.gz

Download URL pytest_structlog-1.2.tar.gz
Size 13.3 kB
Tags Source
SHA-256 checksum
How to use checksums
11b37487663a990bcd490da2e68e2f96b0ecd6a1704f5e82561d5840bd321a60
BLAKE2b-256 checksum
How to use checksums
9471177ef678fde8257c10ae822080811467c0fc893c17daac4c065e0836cd63
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/6.2.0 CPython/3.13.2

Release files / pytest_structlog-1.2-py3-none-any.whl

Download URL pytest_structlog-1.2-py3-none-any.whl
Size 8.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
a5659f6b7d43aa53cf8090075deadad35a6bf1899073ea18118e299232d3d6f0
BLAKE2b-256 checksum
How to use checksums
803fcce51dfeb5f1956a30f480611921e9a899ae5cc5f41bb24858ac99401b17
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/6.2.0 CPython/3.13.2

Security for pytest-structlog 1.2

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page