Skip to main content

Structured logging assertions

Project description

actions pypi pyversions 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 your_lib import spline_reticulator
import pytest_structlog

def test_spline_reticulator(log: pytest_structlog.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

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.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

pytest_structlog-1.0.tar.gz (12.3 kB view hashes)

Uploaded Source

Built Distribution

pytest_structlog-1.0-py3-none-any.whl (8.2 kB view hashes)

Uploaded Python 3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page