Modules, imports, and testing with pytest

What import does

The first import settings finds settings.py on sys.path, creates a module object, runs the file top to bottom to fill it, and stores it in sys.modules. Every later import settings, anywhere in the program, finds it there and runs nothing. A module is a singleton namespace; module-level code is one-time setup.

The two import forms bind different things:

• import settings binds the name settings to the module object. settings.LEVEL is looked up on every use, so it sees changes.
• from settings import LEVEL binds a name LEVEL in your own namespace to the object settings.LEVEL refers to at that moment, once. If the module's attribute is rebound later, your LEVEL still refers to the old object.

__name__ is the module's name when imported and "__main__" when the file is run as a script, which is what if __name__ == "__main__": checks. A package is a directory of modules, usually with an __init__.py that runs when the package is imported; inside it, from . import sibling is a relative import.

1import importlib2import os3import sys4import tempfile5 6 7def write(folder, name, source):8    with open(os.path.join(folder, name), "w") as f:9        f.write(source)10 11 12def run():13    folder = tempfile.mkdtemp()14    log = os.path.join(folder, "log.txt")15    write(folder, "settings.py",16          f"with open({log!r}, 'a') as f:\n"17          "    f.write('executed ')\n"18          "LEVEL = 'info'\n")19    write(folder, "a.py", "from b import helper\nVALUE = 1\n")20    write(folder, "b.py", "from a import VALUE\n\ndef helper():\n    return VALUE\n")21    sys.path.insert(0, folder)22    try:23        import settings24        import settings as again25        from settings import LEVEL26        settings.LEVEL = "debug"27        level_seen_by_module = settings.LEVEL28        with open(log) as f:29            before_reload = len(f.read().split())30        importlib.reload(settings)31        with open(log) as f:32            after_reload = len(f.read().split())33        try:34            import a35            circular = "imported"36        except ImportError as e:37            circular = f"ImportError: {str(e).split(' (/')[0]}"38        return {39            "same_object": settings is again,40            "executions_after_two_imports": before_reload,41            "executions_after_reload": after_reload,42            "module_LEVEL": level_seen_by_module,43            "from_imported_LEVEL": LEVEL,44            "module_name": settings.__name__,45            "circular": circular,46        }47    finally:48        sys.path.remove(folder)49        for name in ("settings", "a", "b"):50            sys.modules.pop(name, None)

A circular import — a imports b while b imports a — leaves one of them half-run when the other asks for a name, and fails with "cannot import name ... from partially initialized module" (shown in circular above). The fixes are structural: move the shared piece into a third module, or import inside the function that needs it.

Testing with pytest

pytest (a third-party package; the snippet below is an illustration, not run here) collects files named test_*.py or *_test.py and, in them, functions whose names start with test. Tests use the plain assert statement: pytest rewrites asserts in test modules so a failure reports the values involved.

import pytest
from shop.pricing import total

@pytest.fixture
def cart():
    items = [("tea", 2.5), ("cake", 4.0)]   # setup
    yield items
    items.clear()                            # teardown, after the test

def test_total(cart):                        # fixtures arrive by name
    assert total(cart) == pytest.approx(6.5)

@pytest.mark.parametrize("raw, expected", [("10", 10), (" 7 ", 7)])
def test_parse(raw, expected):
    assert int(raw) == expected

def test_rejects_text():
    with pytest.raises(ValueError, match="invalid literal"):
        int("ten")

pytest.raises passes when the block raises that type or a subclass, and match= is a regular expression searched for in the exception's message. pytest.approx exists because binary floats rarely add up exactly: is false (the second example below shows it, with the standard library's as the tolerant comparison). A fixture runs once per test by default; or (also , ) shares one instance more widely, which is why a fixture that hands out mutable state is usually left at the default scope.

1import math2import os3import sys4import tempfile5from unittest import mock6 7 8def write(folder, name, source):9    with open(os.path.join(folder, name), "w") as f:10        f.write(source)11 12 13def run():14    folder = tempfile.mkdtemp()15    write(folder, "pricing.py", "def rate():\n    return 0.2\n")16    write(folder, "checkout.py",17          "from pricing import rate\n\n"18          "def total(net):\n    return round(net * (1 + rate()), 2)\n")19    sys.path.insert(0, folder)20    try:21        import checkout22        real = checkout.total(100)23        with mock.patch("pricing.rate", return_value=0.5):24            patched_definition = checkout.total(100)25        with mock.patch("checkout.rate", return_value=0.5):26            patched_lookup = checkout.total(100)27        return {28            "real": real,29            "patched_pricing_rate": patched_definition,30            "patched_checkout_rate": patched_lookup,31            "float_equal": 0.1 + 0.2 == 0.3,32            "float_close": math.isclose(0.1 + 0.2, 0.3),33        }34    finally:35        sys.path.remove(folder)36        for name in ("pricing", "checkout"):37            sys.modules.pop(name, None)

Common mistakes

• Patching the module that defines a function when the code under test imported it with from ... import. The test runs against the real one.
• Putting work with side effects (connecting, reading files) at module level. It runs on first import, including when tests import the module.
• Comparing computed floats with == in a test instead of pytest.approx.
• Expecting a second import to re-run a module after editing it. It is cached; importlib.reload re-runs it, and existing from-imports still hold the old objects.

What interviewers ask

• What happens when you import a module twice? It runs once and is cached in sys.modules; the second import is a dictionary lookup.
• How do you fix a circular import? Extract the shared code into a module both can import, or defer one import into a function.
• Where do you patch a dependency in a test? Where the code under test looks it up: the importing module's namespace.
• What is a pytest fixture? A function whose result is injected into tests by parameter name, with setup before yield, teardown after, and a scope that decides how often it runs.