Unit Testing - Testing Individual Components

diagram why most of your tests should be unit tests mermaid

  flowchart TD
  A["end-to-end -- a few"] --> B["slow, brittle, but proves the whole thing works"]
  C["integration -- some"] --> D["real boundaries: database, HTTP, files"]
  E["unit -- many"] --> F["milliseconds, no I/O, a failure names the function"]
  G["inverted: mostly end-to-end"] --> H["slow suite, vague failures, people stop running it"]

The shape is about cost, not importance. A unit test runs in milliseconds and points at one function, so a failure names the bug. An end-to-end test exercises everything at once and takes seconds, so a failure tells you something is wrong somewhere. You want a few of the slow, broad ones and a great many of the fast, narrow ones.

What is a “unit”?

A unit is the smallest testable piece of your code.

Usually:

a function
a method
a small class

What unit tests should be

fast (no DB, no network)
deterministic (same input → same output)
focused (one behavior per test)

What unit tests should avoid

real HTTP calls
real databases
time-dependent behavior (unless controlled)

Example unit logic

price.py

def apply_discount(price: float, percent: float) -> float:
    if percent < 0 or percent > 100:
        raise ValueError("percent must be between 0 and 100")
    return round(price * (1 - percent / 100), 2)

A unit test for this function is small and has no dependencies.

Key takeaway

Unit tests are your fastest safety net for refactoring.

🧪 Try It Yourself

Exercise 1 – Write a unittest TestCase

Exercise 2 – assertRaises

Exercise 3 – setUp and tearDown

pch.coffeeTagline

pch.coffeeCta

pch.feedbackHeading

pch.feedbackSubheading