Testing Python with pytest

pytest discovers test functions and reports assertion differences clearly. A test should fail for one understandable reason. Test names describe the rule, not implementation steps. Exceptions are behavior too and can be checked with pytest.raises.

The central idea in this lesson is regression protection. Read the rule, predict a concrete outcome, and then run the smallest example that can confirm or reject the prediction. This separates knowledge from familiarity with syntax.

Parametrize a small table of boundary inputs instead of copying a test body. Fixtures are useful for explicit reusable setup, but deep fixture chains obscure the scenario. tmp_path provides isolated filesystem space.

def shipping_cost(weight):
  if weight <= 0:
      raise ValueError("weight must be positive")
  return 5.0 if weight <= 2 else 8.5

cases = [(0.5, 5.0), (2.0, 5.0), (2.1, 8.5)]
for weight, expected in cases:
  assert shipping_cost(weight) == expected
print("3 boundary cases passed")

3 boundary cases passed

Trace the example before running it. Identify each input, transformation, returned value, and side effect. Then change one boundary value and explain why the new behavior follows from the rule rather than memorizing the output.

Do not assert private implementation details, call real external services, depend on test order, or sleep to coordinate timing. A mock is a design tool for a boundary—not a way to make every collaborator imaginary.

Turn the concept into a repeatable workflow: write down the expected behavior, implement one coherent change, run a representative example, and retain a regression check. If the result surprises you, capture the exact input and error before changing anything.

Review the program for names, boundaries, and hidden side effects. A solution is complete when another developer can understand its contract, reproduce its setup, and verify both the successful path and one meaningful failure path.