Defines a pytest fixture with module scope, allowing expensive setup to be performed once and reused by multiple tests within the same module.

Signals to pytest that the decorated function should be treated as a fixture whose lifetime is bound to the module, enabling efficient resource sharing.

When a test module requires a costly resource (e.g., database connection, server instance) that can be safely reused across all tests in that module without causing interference.

Used in test modules where expensive setup is needed and the fixture’s state is either immutable or carefully reset between tests to avoid cross‑test contamination.

@pytest.fixture(scope='module')

@pytest.fixture(scope=<scope_literal>)

• Used with fixture functions that return resources such as database connections
• API clients
• or temporary directories
• often combined with @pytest.mark.usefixtures or requested as arguments in test functions.

• scope='function' (default
• per‑test fixture)
• scope='class' (per‑test‑class fixture)
• scope='session' (per‑test‑session fixture). Trade‑offs: broader scope increases reuse but raises risk of state leakage
• narrower scope increases isolation but adds setup/teardown overhead.

1. Forgetting quotes around the scope value (e.g., scope=module) → NameError: name 'module' is not defined because pytest treats module as a variable. 2. Using an invalid scope string (e.g., scope='invalid') → ValueError: invalid scope 'invalid'. 3. Omitting the pytest import → NameError: name 'pytest' is not defined. 4. Placing the decorator after the function definition (def foo(): @pytest.fixture ...) → SyntaxError: invalid syntax. 5. Returning a mutable object from a module‑scoped fixture without resetting its state → tests inadvertently share state, causing flaky failures.

@pytest.fixture(scope='function') – fixture runs once per test function (default). @pytest.fixture(scope='class') – fixture runs once per test class. @pytest.fixture(scope='session') – fixture runs once per test session. @pytest.fixture(autouse=True) – fixture is automatically used without being requested in test signatures.

Coming from unittest: may expect setUp/tearDown to run per test; in pytest, a module‑scoped fixture runs once per module, requiring explicit teardown via yield or addfinalizer. Coming from JUnit: may expect @BeforeAll equivalent; in pytest, a module‑scoped fixture serves a similar purpose but is requested as a function argument rather than inherited via inheritance.

• @pytest.fixture(scope='function')
• @pytest.fixture(scope='class')
• @pytest.fixture(scope='session')
• @pytest.fixture(autouse=True)

Avoid using module‑scoped fixtures for mutable state that can cause test interference; prefer function scope for isolated state. Module‑scoped fixtures reduce setup/teardown overhead, improving test suite speed, but may increase memory footprint if resources persist for the module’s lifetime. A subtle boundary: if a test in the module mutates the fixture’s return value and another test relies on the original state, the latter may fail non‑deterministically unless the fixture resets the state.

Ensures expensive setup (e.g., starting a server) occurs once per test module, cutting test suite execution time while still allowing safe sharing of immutable or carefully managed resources.

Think of a module‑scoped fixture as a single coffee machine shared by all coworkers in an office for the morning shift—everyone gets coffee from the same machine, but if someone changes the brew strength, it affects everyone else.

The scope argument can also be a callable returning a string, but this pattern is rarely used in practice.

Progress to using session‑scoped fixtures for resources that can safely persist across the entire test suite, or combine module‑scoped fixtures with autouse=True for implicit setup.