Introduction

Pytest deprecation warnings are useful when they point to code you still control, but they become noisy when the warning comes from pytest internals or an outdated plugin that your team has not replaced yet. The right fix is usually selective filtering, not turning warnings off globally.

Start by Identifying the Warning Source

Before suppressing anything, capture the exact warning once. You need three details:

• the warning class
• the message text
• whether it comes from your code, pytest, or a plugin

That distinction matters. If your own test utilities trigger the warning, fix the code. If the warning comes from a third-party plugin, a temporary suppression may be reasonable while you upgrade or replace that dependency.

Pytest uses Python's warnings system, so the filtering rules come from normal warning filters rather than a special hidden mechanism.

Use filterwarnings in pytest.ini

The most maintainable project-wide solution is a targeted rule in pytest.ini:

[pytest]
filterwarnings =
    ignore:.*py\.path.*:DeprecationWarning

That tells pytest to ignore DeprecationWarning messages whose text matches the regular expression. You can also be stricter and make unexpected warnings fail the run:

1[pytest]
2filterwarnings =
3    error
4    ignore:.*py\.path.*:DeprecationWarning

This pattern is strong for CI because it silences the one warning you already understand while keeping the rest visible.

Suppress Warnings for a Single Test or Module

If only one part of the suite needs the suppression, keep the filter close to the test. Pytest supports filterwarnings markers:

1import pytest
2
3@pytest.mark.filterwarnings("ignore:.*legacy plugin path.*:DeprecationWarning")
4def test_old_integration_still_runs():
5    assert 2 + 2 == 4

You can also use Python's warnings module directly inside a narrow scope:

1import warnings
2
3def test_local_warning_filter():
4    with warnings.catch_warnings():
5        warnings.filterwarnings(
6            "ignore",
7            message=r".*legacy plugin path.*",
8            category=DeprecationWarning,
9        )
10        assert "abc".upper() == "ABC"

Local suppression is often better than a repository-wide rule because it does not weaken the rest of the suite.

One-Off Command-Line Filtering

When you are debugging locally or testing a CI hypothesis, you can pass a warning filter on the command line:

pytest -W "ignore:.*py\.path.*:DeprecationWarning"

This is useful when you want to prove that a specific message is the problem before committing configuration changes. Once the filter is known to be correct, move it into pytest.ini or a test-level marker so the whole team gets the same behavior.

What Not to Do

Pytest offers blunt switches such as --disable-warnings. They reduce noise, but they also hide information you probably still need. The same is true of disabling the warnings plugin entirely for normal test runs.

Use those broad switches only for short-lived local debugging sessions. For everyday development and CI, targeted filtering is safer because it keeps new warnings visible.

Prefer Dependency Cleanup Over Permanent Suppression

Warnings from pytest internals often mean an older plugin is using an API that is on the way out. If the warning mentions a plugin path, the long-term fix is usually one of these:

• upgrade the plugin
• pin pytest temporarily while you schedule the upgrade
• remove the plugin if it is obsolete

Suppression is still valuable, but it should be treated as an explicit temporary workaround. Put a short comment beside the filter in your config if the reason is not obvious.

A Practical Configuration Pattern

Many teams adopt a configuration that treats most warnings as errors but whitelists a small number of known issues:

1[pytest]
2filterwarnings =
3    error
4    ignore:.*py\.path.*:DeprecationWarning
5    ignore:.*some-old-plugin.*:PendingDeprecationWarning

That makes test output strict without being unrealistic. When the plugin is upgraded, delete the matching ignore rule and keep the suite clean.

Common Pitfalls

The most common mistake is suppressing all DeprecationWarning messages just to quiet the console. That hides warnings from your own code and makes future upgrades harder.

Another mistake is using a filter expression that is too broad. A message pattern like .*deprecated.* might catch several unrelated warnings later. Make the message match as specific as possible.

Teams also forget that local filters are often enough. If only one flaky legacy integration triggers the warning, there is no reason to soften the whole suite.

Summary

• Identify the warning's source before suppressing it.
• Prefer targeted filterwarnings rules over global warning suppression.
• Use pytest.ini for project-wide known warnings and markers for local cases.
• Treat plugin-driven internal deprecations as a dependency maintenance issue, not just an output problem.
• Keep unexpected warnings visible so upgrades do not fail silently later.