{"title":"Testing Basics","description":"","content":"Testing is how you find out, in advance, whether your code does what you think it does. Without tests, the only way to know if a change broke something is to run the program by hand, click around, and hope you covered every path. With tests, you write the expectations once and let the machine re-check them every time you change a line. This lesson covers the ideas behind testing: why it matters, what kinds of tests there are, and what makes a good test.\n\n---\n\n# Why Testing Matters\n\nA working program at one point in time is not the same as a program that stays correct as it changes. The moment you add a feature, fix a bug, upgrade a library, or rename a function, something else in the code might quietly break. Testing is the discipline that catches those breakages early, ideally seconds after you cause them.\n\nFour concrete reasons to write tests.\n\n**Confidence to refactor.** Code you're afraid to touch is dead weight. If you don't know whether changing a function will break the checkout flow, you leave the function alone. Tests reverse that fear: you change the code, run the tests, and either they pass (you're done) or they fail (you know exactly what broke). Refactoring becomes routine instead of risky.\n\n**Catching regressions.** A regression is a bug that re-appears after being fixed, or a new bug introduced by an unrelated change. Tests catch them because the test for the original bug is still running. The first time you fix \"discount went negative when the cart was empty,\" you also write a test that asserts the discount is zero on an empty cart. Six months later, when someone reworks the discount engine, that test fails the instant the bug comes back.\n\n**An executable specification.** Tests describe what the code is supposed to do, in code. A test named `test_ten_percent_discount_on_hundred_dollar_cart_returns_ninety` is more precise than a wiki page, and it can't drift out of date because if it does, it fails. New developers reading the test suite learn the system faster than they would by reading the implementation, because the tests show intent: inputs in, expected outputs out.\n\n**Faster debugging.** When you find a bug, the first thing to do (before fixing it) is write a test that reproduces it. Now you have a one-keystroke way to check if your fix works, and the test stays in the suite forever as protection against the same bug coming back. Without that test, debugging becomes a manual loop: change code, restart the program, click through to the broken screen, repeat. With it, the loop is one command and a second of waiting.\n\nHere's a tiny taste of what a test looks like, using only `assert`:\n\n\n```python\ndef cart_total(prices):\n return sum(prices)\n\n# A \"test\": run the function with a known input and check the result.\nresult = cart_total([19.99, 29.99, 9.99])\nassert result == 59.97, f\"expected 59.97, got {result}\"\nprint(\"test passed\")\n```\n\n\nThat's it. A test is a small program that calls the code you wrote and checks the answer. The assertion is the part that decides pass or fail. Everything we're about to cover (frameworks, fixtures, mocking, coverage) is machinery built on top of this same idea. There's a secondary benefit worth calling out: tests change how you write code. When you know a function will be tested, you tend to give it a clear input and a clear output, fewer side effects, and a smaller surface area. Code that's easy to test is usually code that's easy to read, easy to reuse, and easy to debug. Writing the test first (or just thinking about how you'd test the function before you finish it) nudges the design in a good direction even before you run the test.\n\nA separate angle is what happens to the team, not just the code. When a junior developer joins, the test suite is the fastest way for them to start contributing. They make a change, run the tests, and find out within seconds whether they've broken anything. Without tests, they're afraid to touch anything, ask senior developers to review every line, and learn the codebase slowly. With tests, they can experiment, see immediate feedback, and build a mental model from the test names alone. Onboarding time drops measurably in well-tested projects.\n\n---\n\n# The Three Kinds of Tests\n\nTests come in different sizes, and the size matters. A test that exercises one function in isolation is fundamentally different from one that spins up your whole application and clicks through the checkout page. Both are useful, but for different reasons. The community has settled on three broad categories.\n\n**Unit tests** check one small piece of code in isolation. \"One small piece\" usually means one function, one method, or one class. A unit test for `apply_discount(100, 10)` calls that function with those exact arguments and asserts the result is `90`. It doesn't talk to a database, doesn't open a file, doesn't make a network call. If a unit test fails, you know exactly which function broke, because the test only exercised one.\n\n**Integration tests** check that two or more pieces work together. The pieces might be functions in your own code, or your code talking to a database, or your code calling an external library. The defining feature is that the test exercises real connections between components, not just one component on its own. An integration test for a cart system might create a real cart, add real items, write the cart to a real SQLite database, and read it back to check the totals matched.\n\n**End-to-end tests** (also called E2E or system tests) check the whole application from the outside. They simulate a user: open the homepage, click \"add to cart,\" fill in checkout, submit the order. They exercise every layer (UI, backend, database, external services) the way a real customer would. If an E2E test passes, you have strong evidence the entire flow works. If it fails, the cause could be in any of those layers, which is why diagnosing E2E failures takes longer.\n\nHere's a side-by-side comparison.\n\n\n| Kind | What it tests | Speed | Stability | When it catches a bug |\n| --- | --- | --- | --- | --- |\n| Unit | One function or class, isolated | Very fast (milliseconds) | Very stable | Immediately, exact location |\n| Integration | Two or more components together | Slower (hundreds of ms) | Mostly stable | Soon, area is known |\n| End-to-end | The full app, like a user would | Slow (seconds to minutes) | Often flaky | Late, root cause unclear |\n\n\nThe three sizes are complementary, not competing. Unit tests give you fast feedback and precise failure messages. Integration tests catch bugs that only appear when pieces meet (a function returns `None` in a case the caller didn't expect, two modules disagree on the format of a dictionary, the SQL query reads back a different shape than what was written). End-to-end tests catch bugs no smaller test could see: the buttons on the page are wired to the wrong handlers, the checkout submit silently swallows errors, the production config disables a feature the dev config enables.\n\nA small e-commerce illustration of all three.\n\n\n```python\n# UNIT: tests one function in isolation, no external state.\ndef apply_discount(price, percent):\n return price * (1 - percent / 100)\n\ndef test_apply_discount_unit():\n assert apply_discount(100, 10) == 90.0\n\ntest_apply_discount_unit()\nprint(\"unit test passed\")\n```\n\n\nThe unit test calls `apply_discount` with two values, checks the answer, done. It would still pass if the entire rest of your application were on fire.\n\n\n```python\n# INTEGRATION: tests that two pieces work together.\ndef apply_discount(price, percent):\n return price * (1 - percent / 100)\n\ndef cart_total(prices, discount_percent):\n subtotal = sum(prices)\n return apply_discount(subtotal, discount_percent)\n\ndef test_cart_total_integration():\n prices = [19.99, 29.99, 9.99]\n # cart_total calls apply_discount, so we're testing both together.\n assert round(cart_total(prices, 10), 2) == 53.97\n\ntest_cart_total_integration()\nprint(\"integration test passed\")\n```\n\n\nThis one calls `cart_total`, which in turn calls `apply_discount`. If either function has a bug that only shows up when they're combined (a unit conversion error, a wrong rounding rule), this test catches it where the unit tests for each function might not have.\n\nEnd-to-end is harder to show in a script because it usually involves a real browser or HTTP client driving a real server. The shape is \"start the application, hit the homepage URL, simulate clicks, assert the resulting page contains the expected text.\" Tools like `selenium`, `playwright`, and `requests` against a running server are the typical way. We won't write one here; the point is just to recognize it as the largest, slowest, most realistic kind of test.\n\n\n> **INFO**\n>\n> **Cost:** A unit test typically runs in under a millisecond. An integration test runs in tens to hundreds of milliseconds, depending on what it touches. An end-to-end test runs in seconds to minutes per case. If your suite is mostly E2E tests, your feedback loop is minutes instead of seconds, and developers stop running it.\n\n\nThe boundaries between the three kinds aren't always sharp. A test that calls one function which happens to call a helper function in the same module looks like a unit test to most people, even though it technically exercises two functions. A test that uses an in-memory SQLite database instead of a real PostgreSQL server is sometimes called a unit test (because it's fast and isolated) and sometimes an integration test (because it talks to a database). Don't get too hung up on the labels. The useful question is: how isolated is the test, how fast is it, and what does it tell you when it fails. Those three answers are more important than which bucket you put it in.\n\nOne more practical note. Different teams draw the line in different places. Some call any test that touches the file system an \"integration test,\" even if it's only writing to a temp file. Others call it a \"unit test\" because no external service is involved. If you join a new project, ask early what the convention is so the words mean the same thing to everyone.\n\n---\n\n# The Test Pyramid\n\nGiven that the three kinds of tests have different speeds and different failure modes, what mix should you aim for? The widely accepted answer is the **test pyramid**: many unit tests at the bottom, fewer integration tests in the middle, very few end-to-end tests at the top.\n\n\n```mermaid\nflowchart TD\n E2E[End-to-End Tests
Few, slow, full app]:::red\n INT[Integration Tests
Some, medium, components together]:::orange\n UNIT[Unit Tests
Many, fast, single functions]:::cyan\n\n E2E --> INT --> UNIT\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe pyramid shape captures a trade-off. Unit tests are cheap to write and cheap to run, so you can afford lots of them, and they give you the fastest feedback. End-to-end tests are expensive on both axes, so you keep them rare and reserve them for the most important user flows (logging in, adding to cart, completing checkout). Integration tests sit in the middle: enough of them to catch the seams between components, not so many that the suite grinds to a halt.\n\nA rough guideline: for every end-to-end test, you might have ten integration tests, and for every integration test, ten unit tests. That's not a law; it depends on the codebase. The principle is what matters: the bulk of your testing effort should be on small, fast tests, with progressively fewer tests as you go up the pyramid.\n\nThe opposite shape, the **ice-cream cone** (lots of E2E, few unit tests), is a well-known anti-pattern. Teams end up there when they don't trust unit tests (\"they don't prove the app actually works\") and over-invest in E2E (\"at least these click through real screens\"). The result is a slow, flaky suite that nobody wants to run, and a codebase where regressions slip through because the slow tests aren't run on every change. There's a related shape called the **testing trophy**, which some teams prefer for web applications: static analysis (typechecks, linters) at the base, then a heavier band of integration tests, then a smaller band of unit tests, and finally a few E2E tests at the top. The argument is that for code which is mostly glue between frameworks and databases, integration tests give better value per test than tiny unit tests of individual functions. The pyramid is still the safer default for general Python code; the trophy is worth knowing about so you recognize the argument when you see it.\n\nThe reason the pyramid keeps winning in practice is that it matches how bugs actually distribute. Most bugs in real code are logic errors in one function: an off-by-one, a missing edge case, a wrong formula. Unit tests catch those cheaply. Fewer bugs sit at component boundaries (a function returns a dict where the caller expected a list), and integration tests catch those. The rarest class is a bug that only shows up when every layer of the system is wired together, and that's what E2E tests are for. Distributing test count by bug frequency gives you the pyramid.\n\n---\n\n# The AAA Pattern\n\nA test is a small program, and like any program it's easier to read when it has a consistent structure. The most common structure (popular enough that it has a name) is **AAA**: Arrange, Act, Assert. Three sections, in that order, separated by a blank line.\n\n- **Arrange:** set up the data and any state the test needs. Create the cart, build the list of items, configure the discount.\n- **Act:** call the code under test. One line, usually. Compute the total, apply the discount, place the order.\n- **Assert:** check that the result matches expectations. Compare to the value you expect, the structure you expect, the side effect you expect.\n\nHere's a test with the three sections labeled.\n\n\n```python\ndef apply_discount(price, percent):\n return price * (1 - percent / 100)\n\ndef test_ten_percent_discount_on_hundred():\n # Arrange\n price = 100.0\n discount_percent = 10.0\n\n # Act\n result = apply_discount(price, discount_percent)\n\n # Assert\n assert result == 90.0, f\"expected 90.0, got {result}\"\n\ntest_ten_percent_discount_on_hundred()\nprint(\"test passed\")\n```\n\n\nThree things, in order. The Arrange section sets up the inputs. The Act section is one line: the call to the function being tested. The Assert section is one line: the check on the result. You don't actually have to write the comments; once you've seen the pattern, the blank lines do the work. The structure becomes a habit.\n\nThe pattern matters because it forces you to think clearly. If you can't separate setup from the call from the check, your test is doing too much or your code is doing too much. A common smell is a test where the \"act\" step is three or four calls (because the function under test needs a bunch of related calls to do anything useful). That's usually a sign the function should be split, or the test should focus on a smaller piece.\n\nA slightly larger example with a cart.\n\n\n```python\ndef cart_total(prices, discount_percent):\n subtotal = sum(prices)\n discount = subtotal * discount_percent / 100\n return round(subtotal - discount, 2)\n\ndef test_cart_total_with_three_items_and_ten_percent_off():\n # Arrange: a cart with three items and a 10% discount.\n prices = [29.99, 14.99, 9.99]\n discount_percent = 10.0\n\n # Act: compute the total.\n total = cart_total(prices, discount_percent)\n\n # Assert: subtotal is 54.97, minus 10% is 49.473, rounded to 49.47.\n assert total == 49.47, f\"expected 49.47, got {total}\"\n\ntest_cart_total_with_three_items_and_ten_percent_off()\nprint(\"cart total test passed\")\n```\n\n\nThe name of the test tells you what it's checking before you read a single line of code: `cart_total_with_three_items_and_ten_percent_off`. Combined with the AAA structure, the body is almost redundant: arrange three items and a 10% discount, act by calling `cart_total`, assert the result is the expected value.\n\nSome teams write a fourth A, **Annotate** or **Arrange-Act-Assert-Annotate**, where the assertion message documents what was expected and why. Whether you do that with a comment, with the message argument to `assert`, or with a descriptive test name is a style choice. The important part is that anyone reading the test can immediately tell what's being tested and what answer was expected.\n\nAnother variant of the same idea goes by the name **Given-When-Then** and comes from the behavior-driven testing community. The mapping is direct: Given is Arrange, When is Act, Then is Assert. Some teams write tests that read almost like English by using those words explicitly:\n\n\n```python\ndef test_a_customer_with_a_full_cart_can_check_out():\n # Given a customer with a cart of three items\n cart = [{\"name\": \"USB Cable\", \"price\": 9.99, \"quantity\": 2}]\n customer = {\"id\": 42, \"email\": \"alex@example.com\"}\n\n # When the customer checks out\n order = create_order(customer, cart)\n\n # Then the order total matches the cart total\n assert order[\"total\"] == 19.98\n```\n\n\nThe mechanics are identical to AAA; the comments are just phrased differently. Pick whichever vocabulary feels more natural for your team. The structure (three labeled sections in a specific order) is the part that matters, not which set of three words you use.\n\nOne pitfall with AAA: it's tempting to add a fourth section, \"Cleanup,\" at the bottom of every test. Most of the time you don't need one, because the test's local variables go out of scope when the function returns and the garbage collector handles the rest. When you do need cleanup (closing a file, dropping a table, removing a temporary directory), put it in the framework's teardown hook or a `pytest` fixture, not at the bottom of the test. The reason is that a `try/except` or an early `return` could skip the cleanup line, leaving you with a leaked resource. Fixtures use Python's exception handling to guarantee teardown runs no matter what; manual cleanup at the bottom doesn't.\n\n---\n\n# What Makes a Good Test\n\nNot every test is a good test. A test can pass and still be misleading, fragile, or slow enough to discourage running the suite. The community has converged on a handful of properties that distinguish good tests from bad ones. Some authors use the acronym **FIRST** (Fast, Independent, Repeatable, Self-validating, Timely). We'll touch on the same ideas here without leaning on the acronym.\n\n**Fast.** A test should run in milliseconds, ideally microseconds. If a single unit test takes a tenth of a second, a suite of 1,000 of them takes nearly two minutes, which is too long to run on every save. Speed comes from isolating the test from slow things: no disk I/O, no network calls, no real databases. A test that imports a 200MB machine-learning model into memory just to check a string parser is not fast, and the slowness will spread.\n\n**Isolated.** A test should not depend on, or interfere with, any other test. Running `test_a` before `test_b` should give the same result as running them in the opposite order, or running only one of them. Tests that share state through global variables, files on disk, or rows in a shared database are not isolated; they pass or fail based on what else ran first, which makes failures impossible to diagnose. The cure is to give each test its own data and clean up after itself.\n\n**Deterministic.** A test should produce the same result every time, given the same code. Tests that depend on the current time, on random numbers, on the order of items in a dictionary (before Python 3.7), or on the response time of a remote server are non-deterministic. They pass on Tuesday, fail on Wednesday for no apparent reason, and erode trust in the suite. Fix non-determinism by controlling the inputs: pass in the time, seed the random generator, mock the network call.\n\n**Readable.** A test is documentation. Someone reading the test six months from now should be able to tell, at a glance, what the test is checking and what answer it expects. The AAA structure helps. So do descriptive names (`test_empty_cart_returns_zero` beats `test_1`), explicit expected values (`assert total == 49.47` beats `assert total == expected_total`, where `expected_total` is computed three lines up using the same formula as the code), and a single concept per test.\n\n**One thing per test.** Each test should check one specific behavior. If you write a test that calls five functions and makes ten assertions, the failure message tells you something is wrong, but not which something. Worse, the first failing assertion stops the test, so the other nine don't even run. Split such tests into separate tests, each named for the behavior it checks. The suite gets bigger, but each failure pinpoints the bug.\n\nThe shape below summarizes the five properties together.\n\n\n```mermaid\nflowchart LR\n T[A good test]:::cyan\n F[Fast
milliseconds]:::green\n I[Isolated
no shared state]:::green\n D[Deterministic
same input
same output]:::green\n R[Readable
self-describing]:::green\n O[One thing
per test]:::green\n\n T --> F\n T --> I\n T --> D\n T --> R\n T --> O\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nA test that hits four out of five is still useful. A test that hits zero out of five is worse than no test: it gives false confidence when it passes and offers no help when it fails. As you write tests over the next few chapters, these properties are the lens to check your work against.\n\nA few common anti-patterns are worth recognizing now, because they undermine these properties:\n\n- **Tests that order-depend.** Two tests share a global cart, the first adds an item, the second relies on the item already being there. Running the second test alone fails. Running the second test before the first fails. Tests must work in any order, including alone.\n- **Tests that depend on the wall clock.** A test that fails on the last day of the month because the date math wrapped wrong is a real bug, but it's also a flaky test for 11 months of the year. The fix is to pass time in as a parameter, or use a mock clock.\n- **Tests that compute the expected value with the same formula as the code.** If both have the same bug, the test passes even though the answer is wrong. Always compute the expected value independently (on paper, by hand, or with a different formula) and hard-code it.\n- **Tests that retry until they pass.** Flaky tests are sometimes \"fixed\" by running them three times and counting the test as passed if any of the runs passes. This buries the problem instead of solving it. The flakiness is still there; you've just stopped reporting it.\n- **Tests that assert \"no exception was raised\" and nothing else.** A test that just calls the function with no assertion checks that the function doesn't blow up, which is a weak guarantee. The function could return wrong values, mutate global state, or leave a file half-written, and the test still passes. Always assert something specific about the result.\n\nIf a test you write or inherit shows one of these patterns, treat it as a bug in the test itself, not as a quirk of the suite. Fixing test bugs is part of writing tests.\n\n\n> **INFO**\n>\n> **Cost:** A test suite that takes more than a few seconds to run becomes a chore. Developers run it less often, bugs slip in between runs, and the safety net rots. The single most important property of a healthy suite is that it stays fast. If a test is slow, ask whether it really needs to do what makes it slow, or whether a smaller test could catch the same problem.\n\n\n---\n\n# Testing With Plain `assert`\n\nThe simplest way to write a test in Python uses only what's already in the language. You write a function whose body calls the code under test and uses `assert` to check the result.\n\n\n```python\ndef cart_total(prices):\n return round(sum(prices), 2)\n\n# A handful of \"tests\" using nothing but assert.\ndef test_empty_cart_total_is_zero():\n assert cart_total([]) == 0\n\ndef test_single_item_cart_total():\n assert cart_total([19.99]) == 19.99\n\ndef test_three_item_cart_total():\n assert cart_total([19.99, 29.99, 9.99]) == 59.97\n\n# Run them by hand.\ntest_empty_cart_total_is_zero()\ntest_single_item_cart_total()\ntest_three_item_cart_total()\nprint(\"all three tests passed\")\n```\n\n\nThree tests, three functions, called in order. If any assertion fails, the script stops with `AssertionError` and the others don't run. This is, technically, testing.\n\nIt's also pretty miserable to do at any scale. A few things you'll quickly miss.\n\n**Better error messages.** When `assert cart_total([19.99]) == 19.99` fails, plain Python just says `AssertionError`. You don't know what `cart_total([19.99])` actually returned. To get a useful message, you have to type it yourself: `assert cart_total([19.99]) == 19.99, f\"expected 19.99, got {cart_total([19.99])}\"`. Test frameworks introspect the expression and show both sides automatically.\n\n**Test discovery.** With three tests you can call each one by hand. With three hundred, you need a tool that finds every function starting with `test_` in every file in the project and runs them, without you maintaining a manual list. Frameworks do this for you.\n\n**Setup and teardown.** Many tests need a fresh cart, or a clean database, or a temporary directory. Doing that in plain Python means duplicating the setup at the top of every test and the cleanup at the bottom. Frameworks provide fixtures: reusable, named setups you can pull into any test by declaring it as a parameter.\n\n**Reporting.** When all tests pass, you want to see a green count: `42 passed`. When some fail, you want to see which, where, and what each failure looked like, with line numbers and diffs. You don't want to scroll through a wall of tracebacks. Frameworks aggregate results, color them, and summarize.\n\n**Stopping on first failure (or not).** The plain-Python version stops the moment any assertion fails. That's sometimes what you want (fail fast) and sometimes not (run everything, report all the failures at once). Frameworks make this configurable with a flag.\n\n**Slow vs. fast modes.** Frameworks let you mark tests as slow and skip them by default, run only tests matching a name pattern, re-run only the tests that failed last time, and so on. None of that exists in plain Python.\n\nTo make the gap concrete, here's what a plain-`assert` failure looks like compared to what a framework would show.\n\nPlain Python:\n\n\n```python\ntotal = 49.50\nassert total == 49.47\n```\n\n\nThat's it. You know an assertion failed, but not which one (if you had several on the same line), not what the values were, and not which side was wrong. To get more, you have to write the message yourself: `assert total == 49.47, f\"got {total}\"`.\n\nA framework like `pytest` rewrites the assertion at import time and would print something like:\n\n\n```shell\n> assert total == 49.47\nE assert 49.5 == 49.47\n\ndemo.py:2: AssertionError\n```\n\n\nThe actual value (`49.5`), the expected value (`49.47`), and the line number all appear automatically, without you writing a message. For multi-line comparisons (lists, dicts, strings), `pytest` even prints a diff. That's the kind of quality-of-life improvement that turns testing from a chore into a fast, reliable feedback loop.\n\nThe takeaway is that `assert` is the right building block, and Python has it. What's missing is the framework around it. Frameworks like `unittest` (in the standard library) and `pytest` (the most popular community choice) fill the gap. Both are built on top of the same `assert` idea you just saw.\n\n---\n\n# Test Naming\n\nTests are functions, and like all functions they need names. Test names follow a few conventions worth knowing now, because they're the same in `unittest`, `pytest`, and most other testing tools.\n\n**Start with `test_`.** Test functions are conventionally named `test_`. Both `unittest` and `pytest` discover tests by looking for functions whose names start with `test_`. A function called `verify_cart_total` is invisible to the test runner; rename it to `test_verify_cart_total` (or, better, `test_cart_total_sums_three_items`) and it gets picked up.\n\n**Describe the behavior, not the function.** A name like `test_apply_discount` tells you which function is being tested but not what's being checked. `test_apply_discount_returns_zero_for_full_discount` tells you both. The name should answer: \"What scenario, with what expected outcome?\"\n\n**Be specific about inputs and outputs.** `test_cart_total_for_empty_list_is_zero` is better than `test_empty_cart_total`. `test_discount_percent_above_one_hundred_raises_value_error` is better than `test_invalid_discount`. The reader shouldn't have to open the test body to find out what the test is checking.\n\n**Long names are fine.** Test names are read more often than they're typed, and they show up in failure reports. A test name of 60 characters is normal. A test name of 8 characters (`test_foo`) is almost always a code smell.\n\nSome patterns that work well:\n\n\n| Pattern | Example |\n| --- | --- |\n| `test___` | `test_apply_discount_with_zero_percent_returns_full_price` |\n| `test__` | `test_empty_cart_total_is_zero` |\n| `test__raises__when_` | `test_charge_raises_value_error_when_amount_is_negative` |\n| `test__` | `test_cart_total_with_mixed_quantities` |\n\n\nTest files follow a parallel convention: a module called `cart.py` is tested by `test_cart.py`. Both `unittest` and `pytest` look for files matching `test_*.py` or `*_test.py`, depending on configuration.\n\nTwo layout choices are common in Python projects. The first puts tests in a parallel `tests/` directory at the project root, mirroring the package structure:\n\n\n```shell\nmy_shop/\n cart.py\n discount.py\n orders.py\ntests/\n test_cart.py\n test_discount.py\n test_orders.py\n```\n\n\nThe second co-locates each test file next to the module it tests:\n\n\n```shell\nmy_shop/\n cart.py\n test_cart.py\n discount.py\n test_discount.py\n orders.py\n test_orders.py\n```\n\n\nBoth work. The separate `tests/` directory keeps production code clean and makes it easy to ship without tests in a distribution package. Co-located tests are easier to discover when reading the code (the test for `cart.py` is right there next to it). Many large projects use the separate directory; many small projects use co-location. There's no universal right answer; pick one per project and be consistent.\n\n---\n\n# Putting It Together\n\nA small worked example to close the chapter. We'll write a function, write three tests for it using the AAA pattern, give them descriptive names, and use plain `assert`. The same code rewritten with `unittest` or `pytest` will look very similar; only the framework noise changes.\n\n\n```python\ndef cart_total(prices, discount_percent):\n if discount_percent < 0 or discount_percent > 100:\n raise ValueError(f\"discount must be 0-100, got {discount_percent}\")\n subtotal = sum(prices)\n discount = subtotal * discount_percent / 100\n return round(subtotal - discount, 2)\n\ndef test_empty_cart_total_is_zero():\n # Arrange\n prices = []\n discount_percent = 0\n\n # Act\n total = cart_total(prices, discount_percent)\n\n # Assert\n assert total == 0.0, f\"expected 0.0, got {total}\"\n\ndef test_three_items_with_ten_percent_discount():\n # Arrange\n prices = [29.99, 14.99, 9.99]\n discount_percent = 10\n\n # Act\n total = cart_total(prices, discount_percent)\n\n # Assert: subtotal 54.97, minus 10% = 49.473, rounded = 49.47.\n assert total == 49.47, f\"expected 49.47, got {total}\"\n\ndef test_invalid_discount_raises_value_error():\n # Arrange\n prices = [19.99]\n discount_percent = 150 # out of range\n\n # Act + Assert: call the function and check the exception.\n try:\n cart_total(prices, discount_percent)\n except ValueError as exc:\n assert \"150\" in str(exc), f\"message should mention 150: {exc}\"\n else:\n raise AssertionError(\"expected ValueError, none raised\")\n\n# Run them.\ntest_empty_cart_total_is_zero()\ntest_three_items_with_ten_percent_discount()\ntest_invalid_discount_raises_value_error()\nprint(\"all three tests passed\")\n```\n\n\nThree tests, three different shapes of check. The first verifies an edge case (empty cart). The second verifies the happy path with realistic data. The third verifies error behavior: when given a bad input, the function should raise `ValueError`, and the error message should mention the offending value.\n\nThe error-check pattern (`try`/`except`/`else: raise AssertionError`) is awkward, and `unittest` cleans it up with `assertRaises`. The empty-cart and happy-path tests are already in good shape; they translate almost line-for-line to either framework.\n\nA few things to notice. Each test is named for the scenario, not for the function. Each follows AAA: arrange the inputs, call the function, assert the result. Each test exercises one behavior; you can read the name and predict exactly what's being checked. If any one fails, the message tells you the value that came back. None of them depend on any other test. All three together run in well under a millisecond.\n\nThat's the foundation. Frameworks are conveniences on top of this; they make the syntax cleaner, the failure output richer, and the test runner more capable. The ideas (AAA, descriptive names, fast and isolated checks) stay the same.\n\n---\n\n# The Feedback Loop\n\nThere's one practical idea worth covering before the framework chapters: the **feedback loop**. The whole point of having tests is that you can run them often enough to catch problems while they're cheap to fix. The slower the loop, the less you run it, and the more bugs accumulate between runs.\n\nA typical loop with a good test suite looks like this:\n\n\n```mermaid\nflowchart LR\n A[Write or change
code]:::cyan\n B[Run tests]:::orange\n C{All green?}:::orange\n D[Commit]:::green\n E[Read failure
message]:::red\n F[Fix the code]:::cyan\n\n A --> B --> C\n C -->|Yes| D\n C -->|No| E --> F --> B\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nYou write code, run the tests, and either move on (everything green) or fix what broke. The loop runs many times per hour. Each turn takes a few seconds at most, which is why suite speed matters: if a turn takes a minute, you don't take ten of them per hour, you take one.\n\nThe same loop shows up at three layers in real projects:\n\n1. **Local, on every save.** Some editors (and tools like `pytest-watch` or `entr`) re-run tests automatically when you save a file. The loop is sub-second. Bugs caught here never reach the next layer.\n2. **Pre-commit, before pushing.** A git hook or local command runs the full suite before you push. The loop is seconds to a few minutes. Bugs caught here never reach the team.\n3. **Continuous integration, after pushing.** A CI server (GitHub Actions, GitLab CI, etc.) runs the suite on every push and pull request, often in multiple Python versions or operating systems. The loop is minutes. Bugs caught here are visible to the team but never reach production.\n\nEach layer is wider and slower than the last. The point of having all three is that they catch different things: local catches the obvious, pre-commit catches \"I forgot to run them,\" and CI catches \"works on my machine, fails on Linux.\" A team that runs only the CI suite has the slowest possible loop and ships the most bugs. A team that runs all three has the fastest loop at every layer and ships the fewest.\n\nA concrete number to anchor this. If your suite runs in 2 seconds, you can run it 30 times an hour without thinking about it. If it runs in 2 minutes, you might run it twice an hour, and only the second time after the change feels \"done.\" If it runs in 20 minutes, you run it at the end of the day, or only in CI, and bugs sit uncaught for hours or days. The speed of the suite directly determines how fast you find bugs.\n\nThat's why every chapter from here on cares about test speed. `pytest` is fast. Fixtures avoid duplicating setup. Mocks avoid real network calls. Each technique exists because the cost of slow tests is real, measurable, and felt every single day.\n\n---\n\n# How Many Tests Is Enough?\n\nA question every developer asks early: how do I know when I've written enough tests? There's no exact answer, but a few heuristics help.\n\n**One test per behavior, not per line of code.** A function with one branch needs at least one test, often two (one for each branch). A function with three branches needs at least three. The unit isn't lines, it's distinct behaviors: each `if`, each error case, each edge case is a behavior worth its own test. \"I wrote 100 lines, so I need 100 tests\" is the wrong frame. \"I wrote a function that handles four cases, so I need at least four tests\" is the right frame.\n\n**Cover edge cases explicitly.** For any function that takes a list, write a test for the empty list. For any function that takes a number, write tests for zero, for a negative number, for the largest value you expect, and for one beyond the largest if there's a limit. Edge cases are where bugs hide; the middle of the range usually works fine.\n\n**Cover error paths.** Every place your code raises an exception deserves a test that triggers it. If `add_to_cart(item, quantity=-1)` raises `ValueError`, write a test that calls it with `-1` and asserts the exception. This proves the validation works, and it locks in the message and the type so a later refactor doesn't quietly change the contract.\n\n**Don't test the language.** A test that checks `1 + 1 == 2` is not a useful test. Neither is one that asserts a built-in function does what its documentation says. Your tests should cover your code, not Python's. The line is sometimes fuzzy (testing a thin wrapper around `dict.get` is silly; testing a function that builds a cart from a JSON file isn't), but the principle is clear: if the only thing that could break the test is Python itself, the test isn't pulling its weight.\n\n**Stop when an extra test wouldn't catch anything new.** After you've covered the main behaviors, the edge cases, and the error paths, more tests usually duplicate coverage without adding value. A function with four behaviors and four well-chosen tests is well covered. Writing eight tests for the same function is twice the maintenance burden for the same protection. The goal is meaningful coverage, not maximum coverage.\n\nThere's a separate tool called **code coverage** that measures, line by line, what percentage of your code is exercised by the test suite. High coverage is a good sign but not a guarantee: you can have 100% line coverage and still miss obvious bugs because the test ran the line without asserting the result was right. Low coverage is more useful: if a critical function has 0% coverage, you know for certain it's untested. As a rough target, most teams aim for somewhere between 70% and 90% coverage on production code, with the understanding that the last 10% is often not worth the effort (defensive code that never fires, log statements, glue with no logic in it).\n\nThe honest answer to \"how many tests is enough\" is \"enough that you can refactor with confidence and that a typical bug is caught by an existing test before it gets to production.\" That's a feel that develops with practice. Start with one test per behavior, add tests when you find a bug (write the failing test first, then fix the code), and trust the suite to grow with the codebase.\n\n---\n\n# Quiz","pageType":"python"}

Testing Basics

Get Premium