Pytest catches the pipeline bugs that ship as wrong numbers

Start with the arithmetic on the worst item in that failure list. Swapping `sum` for `mean` in a grouped aggregation replaces each group's total with the total divided by its row count ^[3]. Revenue arriving about 90 percent smaller therefore implies groups averaging roughly ten rows: mean = sum / n, so 0.1 = 1/n gives n = 10 ^[1]. A number that plausible is harder to catch than a crash, because a crash arrives with a timestamp and an owner.

The failure modes in the piece are cheap to test precisely because they are small. A rename upstream turns a join into all-null matches instead of raising ^[2]. A cleaning function meant to drop duplicates takes valid rows with it ^[5]. Both are properties of a function given a fixed input, which is what the author means by writing deterministic checks against deterministic inputs ^[1]. The locale-dependent date parser sits on a different axis ^[4]: it is not the data that changed and not the logic, it is the environment, which is why CI is where it shows up rather than a laptop. The article's day-invariance heuristic routes checks between code tests and data tests ^[7], and this third bucket is the one that gets misfiled, because a test that passes locally and fails in CI looks like flakiness rather than a finding.

What pytest supplies here is modest and well judged. A test is a function whose name starts with `test_`, in a file starting with `test_` or ending in `_test.py`, with no class boilerplate required ^[10]. Assertions use the plain `assert` keyword, and pytest rewrites them so the failure output shows what was actually compared, rather than the `self.assertEqual` ceremony of `unittest` ^[11]. The framework's entire contract with you is a naming convention, which is about as much ceremony as this problem deserves.

The scope boundary the author draws is the load-bearing part: pytest answers whether the code is correct, while dbt test, Great Expectations and Soda answer whether today's data is correct, and a mature platform runs both rather than one ^[8]. That split transfers on one condition. Your transformation logic has to be callable as a function that takes a frame and returns a frame. If the logic lives inside a long SQL string or a notebook cell that also reads and writes storage, there is nothing for a code test to grip, and the split collapses into the data-test column by default.

Adoption cost is one command. `uv add --dev pytest` writes `pytest>=8.3.4` into a `[dependency-groups]` table in `pyproject.toml`, the standardised layout from PEP 735, kept apart from runtime dependencies so consumers of the package never install it ^[9]. Tests then run with `uv run pytest`, which executes inside the project's managed virtual environment without a manual activation step ^[12]. The article promises pandas, Polars and PySpark patterns on top of that base ^[14], and the honest caveat is that the excerpt here stops before the Spark section, so the cost of standing up a session fixture is not something I can price from it. For pandas and Polars, the work is in-process and the setup is what you see above.