How do you write tests in Python with unittest and pytest?

Q: How do you write tests in Python with unittest and pytest?

**Target Audience:** Beginners writing their first tests, and developers who use one framework and need to talk confidently about both. **Difficulty:** Medium **Python version:** The unittest and mock examples were run on CPython 3.11 (python3.11 and the in-page Pyodide 0.25.1 runtime, CPython 3.11.3). The pytest runs were done with pytest 9.1.1 on CPython 3.13, because pytest is not part of the standard library and cannot run in the page. > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:` so you also learn the exact word an interviewer expects. Every output shown, including the pytest reports, was copied from a real run. ## 1. Why This Even Matters — A Story First A bakery makes the same cake every day. On day one the baker tastes it and it is perfect. On day forty they swap the flour supplier, change the oven and add a new icing, and nobody tastes the plain sponge again until a customer complains. A smart baker keeps a

The problem

Question presented to candidate: "Say you have just written a pricing function and a small shopping-cart class. How would you test them in Python? Show me what a test looks like in unittest and in pytest, how you give each test a clean setup, how you test errors, and how you avoid calling a real external API."

What a strong answer should cover:

unittest is the standard library's xUnit framework: subclass unittest.TestCase, name methods test_*, use self.assertEqual / assertRaises, and setUp / tearDown around every test; run with python -m unittest discover.
pytest is the third-party de facto standard: plain functions and the plain assert statement (pytest rewrites asserts to print both sides on failure), and it also runs existing unittest tests unchanged.
Fixtures: pytest injects them by parameter name, yield splits setup from teardown, built-ins such as tmp_path and monkeypatch; @pytest.mark.parametrize turns one test into a table of cases (unittest's nearest is subTest).
Testing failure paths: assertRaises / pytest.raises(..., match=...), and approximate float comparison (assertAlmostEqual, pytest.approx).
Test doubles with unittest.mock: Mock, return_value, side_effect, assert_called_once_with, create_autospec, and patching where the name is looked up, not where it is defined.
Good test hygiene: each test independent, fast and deterministic; no real network, clock or randomness without control.

Clarifying questions expected:

Is the project already on unittest or pytest, and is adding a dev dependency acceptable?
Which dependencies are external (HTTP APIs, databases, the clock) and need to be faked?

Code / implementation expected: Yes — a few real tests in either framework, including one error case and one mocked dependency.

testing
unittest
pytest

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Beginners writing their first tests, and developers who use one framework and need to talk confidently about both. Difficulty: Medium Python version: The unittest and mock examples were run on CPython 3.11 (python3.11 and the in-page Pyodide 0.25.1 runtime, CPython 3.11.3). The pytest runs were done with pytest 9.1.1 on CPython 3.13, because pytest is not part of the standard library and cannot run in the page.

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact word an interviewer expects. Every output shown, including the pytest reports, was copied from a real run.

1. Why This Even Matters — A Story First

A bakery makes the same cake every day. On day one the baker tastes it and it is perfect. On day forty they swap the flour supplier, change the oven and add a n

The solution is hidden so you can try first

15 min read · 11 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

Pythonunittest: TestCase, setUp isolation, assertRaises, subTest and a deliberate failure

Practice

Pythonunittest.mock: return_value, side_effect, autospec, mock_open and where to patch

Practice

PythonA toy pytest: collect test_* functions, inject fixtures by name, parametrize