Why we test

Imagine you maintain the checkout code for a small online bookshop. A colleague changes the VAT calculation to "tidy it up". Nobody notices anything wrong for three weeks, until the accountant finds that every invoice under 100 SAR was undercharged. The change took two minutes. Finding it, refunding, re-issuing invoices and explaining it to customers took days.

A test is code that runs your code with chosen inputs and checks the results automatically. If the colleague's change had broken a test, they would have seen a red failure seconds after making it, before it reached a single customer. This track is about writing tests like that, and about writing code that is easy to test and easy to change.

Checking by eye

Most people start by printing results and looking at them. That is a manual check: you run the code, read the output and decide whether it looks right.

def add_vat(price):
    return round(price * 1.15, 2)

print(add_vat(100))
print(add_vat(19.99))
print(add_vat(0))

Manual checks have three problems:

• You must know the right answer each time and compare it in your head. After the tenth run you stop looking carefully.
• They don't scale. A real program has hundreds of behaviours. Nobody re-checks all of them after every change.
• They are forgotten. The checks live in your head, not in the project, so the next person can't run them.

An automated check writes the expected answer down once, in code. Python's assert statement does this: assert condition does nothing when the condition is true and stops the program with an AssertionError when it is false.

def add_vat(price):
    return round(price * 1.15, 2)

assert add_vat(100) == 115.0
assert add_vat(19.99) == 22.99
assert add_vat(0) == 0
print("All checks passed")

Now the expected answers are part of the code. Anyone can run the checks at any time, and the computer does the comparing. Silence (or a final "passed" message) means every check held.

Regressions

A regression is a bug in something that used to work. Regressions usually come from changes that look harmless: a refactor, a "small" optimisation, a new feature that touches shared code. Here is the colleague's tidy-up. The answer for 100 SAR is still correct, so a quick manual check of one value would pass, but the automated checks catch it immediately.

def add_vat(price):
    # "Simplified": VAT on 100 is 15, so add 15
    return round(price + 15, 2)

assert add_vat(100) == 115.0
assert add_vat(19.99) == 22.99
print("All checks passed")

That last experiment is the most important idea in this track: a test is only as good as the bugs it can catch. Checking add_vat(100) alone cannot tell price * 1.15 apart from price + 15. Good tests use inputs where a wrong implementation would give a different answer: a price with halalas, a zero, a value just past a limit.

What bugs cost

The later a bug is found, the more it costs:

Tests move bug-finding to the top row. They also give you confidence to change code: if the tests still pass after an edit, you haven't broken the behaviours they describe.

def is_late(arrival, start):
    return arrival > start

results = [is_late(9, 8), is_late(8, 8), is_late(7, 8)]
print(results)
assert results == [True, False, False]
print("checks passed")

Tests as functions

Instead of loose asserts at the bottom of a file, put related checks in a function whose name starts with test. Then you can run them on demand, and (from the third lesson) a tool can find and run them all for you.

def test_add_vat():
    assert add_vat(100) == 115.0
    assert add_vat(19.99) == 22.99

test_add_vat()          # run it
print("All tests passed")

In the exercises where you write tests, the grader does something extra: it runs your tests against the correct code (they must pass) and against several deliberately broken versions (at least one of your tests must fail for each). That is exactly the job of a real test suite.