Tests for beginners: why and where to start

Why bother in a learning project

The beginner's first thought: "the project is small, I can see it works". While it's two hundred lines, that's true. After that things get interesting.

Tests let you change code without fear. You fix one place, run the checks and see whether anything else broke. Without them, in a month you'll be afraid to touch your own project.

Tests are documentation that doesn't lie. A comment can go stale; a test can't — it either passes or fails.

Having tests is noticed at interview. A project with tests stands out among hundreds without, because it shows someone thinking about the consequences of their changes.

The kinds

Unit tests. Check one function in isolation. Fast, and there are many.

Integration tests. Check that several parts work together: the request handler reached the database and returned the right thing.

End-to-end tests. Simulate a person's actions in a browser from start to finish. Slow, and there are few.

A sensible ratio for a small project: many unit tests, a few integration ones, two or three end-to-end on the main flows.

Where to start

Not by covering everything. With three places:

1. Logic that's easy to get wrong. Calculations, date handling, string parsing, input validation. That's where bugs live longest.

2. What already broke. Found a bug? Write a test reproducing it, then fix it. That way it doesn't come back.

3. The main flow. One end-to-end test: a person arrives, performs the core action, sees the result. If it passes, the project is alive.

What a test looks like

Three parts: arrange the data, perform the action, check the result.

def test_short_text_not_cut():
    result = shorten("Hello", 10)
    assert result == "Hello"

def test_long_text_cut_with_ellipsis():
    result = shorten("A very long piece of text", 10)
    assert result.endswith("…")
    assert len(result) == 11

Important: one test name, one idea being checked. The name should tell you what broke without reading the code.

What must be covered

The edge cases, where the bugs are:

• empty input;
• a single element;
• a very large value;
• a negative number where positive was expected;
• missing data.

The rule: if a function takes a list, a test for the empty list is always needed.

About coverage

The coverage figure shows how many lines ran during the test suite. Useful as a signal, harmful as a target.

A hundred per cent coverage of meaningless assertions is worse than thirty per cent of meaningful ones. Chasing the number is a common mistake.

What not to test

• Third-party libraries. They're tested without you.
• Trivial wrappers that do nothing but call another function.
• Appearance. A test that breaks when a margin changes will irritate people until it's switched off.

What to do today

Take your project, find a function with complex logic, and write five tests: the ordinary case and four edge cases. Run them. At least one will probably fail — and that's the best illustration of why any of this exists.