Testing with pytest

Also Known As

TL;DR

Explanation

pytest discovers tests by naming convention (test_*.py, *_test.py), uses plain assert statements with introspective failure messages, and provides fixtures via dependency injection (function parameters). Key features: @pytest.fixture for reusable setup/teardown, @pytest.mark.parametrize for data-driven tests, conftest.py for shared fixtures, and marks for grouping tests. The plugin ecosystem (pytest-cov, pytest-mock, pytest-asyncio) covers virtually every testing need.

Common Misconception

Why It Matters

Common Mistakes

• Not using fixtures for shared setup — copy-pasting setup code across tests instead of extracting a fixture.
• Fixtures with too wide a scope — session-scoped fixtures with mutable state bleed between tests.
• Not using parametrize for data-driven tests — writing the same test five times with different inputs.
• Not using conftest.py for shared fixtures — defining fixtures in every test file instead of once.

Code Examples

# unittest style — verbose:
import unittest

class TestUserService(unittest.TestCase):
    def setUp(self):
        self.db = create_test_db()
        self.service = UserService(self.db)

    def test_create_user_success(self):
        result = self.service.create({'email': 'a@b.com', 'name': 'Alice'})
        self.assertEqual(result['email'], 'a@b.com')  # Less informative failure

# pytest style — concise, with fixtures:
import pytest

@pytest.fixture
def user_service():
    db = create_test_db()
    yield UserService(db)
    db.rollback()  # Teardown

@pytest.mark.parametrize('email,name', [
    ('alice@example.com', 'Alice'),
    ('bob@example.com', 'Bob'),
])
def test_create_user(user_service, email, name):
    result = user_service.create({'email': email, 'name': name})
    assert result['email'] == email  # pytest shows actual vs expected on failure

References

• ↗ https://docs.pytest.org/en/stable/

Tags

Related Terms