Writing Your First Test Case

The AAA pattern

A clean test follows Arrange → Act → Assert:

1. Arrange: set up inputs
2. Act: call the code under test
3. Assert: verify output/side effects

Example: function + test

calculator.py

def divide(a: float, b: float) -> float:
    return a / b

test_calculator.py

import unittest
from calculator import divide
 
 
class TestCalculator(unittest.TestCase):
    def test_divide_returns_quotient(self):
        # Arrange
        a, b = 10, 2
 
        # Act
        result = divide(a, b)
 
        # Assert
        self.assertEqual(result, 5)
 
 
if __name__ == "__main__":
    unittest.main()

Test naming tips

Good test names describe behavior:

• test_divide_by_two_returns_half
• test_divide_by_zero_raises

Avoid vague names like test1.

🧪 Try It Yourself

Exercise 1 – Write a unittest TestCase

pch.exerciseTag pch.exerciseTitle

Exercise 2 – assertRaises

pch.exerciseTag pch.exerciseTitle

Exercise 3 – setUp and tearDown

pch.exerciseTag pch.exerciseTitle

Arrange, Act, Assert

Every test has the same three parts, and naming them keeps a test readable when it fails six months later:

diagram Diagram mermaid

  flowchart LR
  A["Arrange
build the inputs"] --> B["Act
call the thing under test"]
  B --> C["Assert
compare against what you expect"]
  C --> P["pass: nothing printed"]
  C --> F["fail: the assertion says what differed"]

tests/test_calc.py

import unittest
from calc import add
 
class TestAdd(unittest.TestCase):
    def test_add(self):
        result = add(2, 3)          # Arrange and Act
        self.assertEqual(result, 5)  # Assert

Three rules the framework enforces, and one convention:

• The class must subclass unittest.TestCase.
• Test methods must start with test — a method named check_add is never run, and nothing warns you.
• Assertions come from self, not the assert statement (the next page shows why).
• The file is conventionally named test_*.py so discovery finds it.

setUp, tearDown, and how often they run

fixtures.py

class TestAdd(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        print("runs ONCE for the whole class")
 
    def setUp(self):
        self.log = ["setUp"]        # runs before EVERY test method
 
    def tearDown(self):
        pass                        # runs after every test method, even if it failed

Measured: setUpClass printed once across eight tests. setUp runs per test, which is what gives each test a clean object to work with — and why one test cannot corrupt another’s state.

Each test must not depend on another

Tests run in alphabetical order by method name, not the order you wrote them. Measured discovery order on a class defining test_add first and test_unexpected_pass last:

actual run order

test_add, test_assertion_messages, test_known_bug, test_raises,
test_raises_message, test_skipif, test_skipped, test_unexpected_pass

A test that only passes after another has run will break the moment someone renames either one.

Running it

commands

python -m unittest tests.test_calc          # one module
python -m unittest discover -s tests -t .   # find everything
python -m unittest discover -v              # name each test as it runs

See it move

sketch The order things actually run in p5.js Pause Restart

setUpClass runs once, setUp runs before every test, and the tests themselves run in alphabetical order rather than the order written.

Check yourself

pch.quizTag pch.quizDefaultTitle

1. You write a method named check_addition inside a TestCase. What happens when you run the suite?

   A it runs like any other test B it is never run, and nothing warns you C it raises a collection error D it runs only with -v
   pch.quizShowAnswer

   B — it is never run, and nothing warns you — unittest collects methods whose names start with test. A misnamed method is silently ignored, which is why a suite can report all-passing while covering nothing.

2. In what order do test methods within a TestCase run?

   A the order they are defined B alphabetically by method name C randomly on each run D by how long they took last time
   pch.quizShowAnswer

   B — alphabetically by method name — Measured: a class defining test_add first and test_unexpected_pass last ran them alphabetically. A test that depends on another running first will break on a rename.

3. How often does setUpClass run compared with setUp?

   A both run before every test B setUpClass runs once per class; setUp runs before every test method C setUpClass runs before every test and setUp once D both run once
   pch.quizShowAnswer

   B — setUpClass runs once per class; setUp runs before every test method — Measured setUpClass printing once across eight tests. Per-test setUp is what gives each test a clean starting state.