How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Parametrising tests — Python Mastery

Day 18 · ~12 min●

You want to test add(a, b) against five input pairs. Naive way:

python

class TestAdd(unittest.TestCase):
    def test_a(self):
        self.assertEqual(add(1, 2), 3)
    def test_b(self):
        self.assertEqual(add(0, 0), 0)
    def test_c(self):
        self.assertEqual(add(-1, 1), 0)
    def test_d(self):
        self.assertEqual(add(10, 20), 30)
    def test_e(self):
        self.assertEqual(add(-5, -5), -10)

Five copies of the same line with different numbers. Feels wrong.

It is. The test logic is identical — only the data differs. pytest has @pytest.mark.parametrize; for unittest the standard pattern is subTest:

python

import unittest

def add(a, b):
    return a + b

class TestAdd(unittest.TestCase):
    def test_pairs(self):
        cases = [
            (1, 2, 3),
            (0, 0, 0),
            (-1, 1, 0),
            (10, 20, 30),
            (-5, -5, -10),
        ]
        for a, b, expected in cases:
            with self.subTest(a=a, b=b):
                self.assertEqual(add(a, b), expected)

result = unittest.main(argv=[''], exit=False, verbosity=0)
print("ran:", result.result.testsRun, "failures:", len(result.result.failures))

What does self.subTest(a=a, b=b) do?

Each iteration becomes its own "sub-test." If one assertion fails, the loop keeps going — you see all the failing pairs in one run, not just the first one. Without subTest, the first failure stops the loop and you only know about pair #1.

And the kwargs to subTest — those are just labels for the failure message?

Right. When a sub-test fails, you'll see something like FAIL: test_pairs (a=10, b=20). Helpful for figuring out which of the five inputs broke.

Parametrising tests

Running the same test logic against many inputs — without N copies of the same code.

`subTest` — the `unittest` pattern

python

class TestAdd(unittest.TestCase):
    def test_pairs(self):
        cases = [
            (1, 2, 3),
            (0, 0, 0),
            (-1, 1, 0),
            (10, 20, 30),
            (-5, -5, -10),
        ]
        for a, b, expected in cases:
            with self.subTest(a=a, b=b):
                self.assertEqual(add(a, b), expected)

What `subTest` gives you

All failures reported. Without subTest, the first assertEqual failure stops the loop. With it, every iteration is independent — the runner reports all five failing pairs at once.
Labelled failures. The kwargs you pass (a=a, b=b) appear in the failure message — you immediately see which input broke.
One test method, many cases. Easy to add cases — just append a tuple. Don't have to write a new method.

`pytest`'s version (for context)

Most real Python projects use pytest, which has a more concise version:

python

import pytest

@pytest.mark.parametrize("a, b, expected", [
    (1, 2, 3),
    (0, 0, 0),
    (-1, 1, 0),
])
def test_add(a, b, expected):
    assert add(a, b) == expected

Same idea, different syntax. Each tuple becomes a separate test. pytest is not available in our in-browser runtime; the subTest pattern works in pure stdlib.

When to parametrise

Same logic, many inputs. You're testing one function against a table of (input, expected) pairs. Parametrise.
Different logic, similar inputs. Don't parametrise — write separate test methods. Forcing them into one loop hides what each is checking.
Edge cases that need special setup. Don't parametrise — the setup variation will fight you. Write a separate test.

Where the cases come from

Good parametrised tests cover:

Happy path — the typical case (add(1, 2) == 3)
Boundaries — zero, empty, max (add(0, 0) == 0)
Negatives / errors — invalid input (add(-1, 1) == 0)
Past bug repros — every bug you've fixed, as a row in the table

The table grows over time. That's fine — it's the cheapest way to keep regressions caught.

Day 18 · ~12 min●

You want to test add(a, b) against five input pairs. Naive way:

python

class TestAdd(unittest.TestCase):
    def test_a(self):
        self.assertEqual(add(1, 2), 3)
    def test_b(self):
        self.assertEqual(add(0, 0), 0)
    def test_c(self):
        self.assertEqual(add(-1, 1), 0)
    def test_d(self):
        self.assertEqual(add(10, 20), 30)
    def test_e(self):
        self.assertEqual(add(-5, -5), -10)

Five copies of the same line with different numbers. Feels wrong.

It is. The test logic is identical — only the data differs. pytest has @pytest.mark.parametrize; for unittest the standard pattern is subTest:

python

import unittest

def add(a, b):
    return a + b

class TestAdd(unittest.TestCase):
    def test_pairs(self):
        cases = [
            (1, 2, 3),
            (0, 0, 0),
            (-1, 1, 0),
            (10, 20, 30),
            (-5, -5, -10),
        ]
        for a, b, expected in cases:
            with self.subTest(a=a, b=b):
                self.assertEqual(add(a, b), expected)

result = unittest.main(argv=[''], exit=False, verbosity=0)
print("ran:", result.result.testsRun, "failures:", len(result.result.failures))

What does self.subTest(a=a, b=b) do?

And the kwargs to subTest — those are just labels for the failure message?

Right. When a sub-test fails, you'll see something like FAIL: test_pairs (a=10, b=20). Helpful for figuring out which of the five inputs broke.

Parametrising tests

Running the same test logic against many inputs — without N copies of the same code.

`subTest` — the `unittest` pattern

python

class TestAdd(unittest.TestCase):
    def test_pairs(self):
        cases = [
            (1, 2, 3),
            (0, 0, 0),
            (-1, 1, 0),
            (10, 20, 30),
            (-5, -5, -10),
        ]
        for a, b, expected in cases:
            with self.subTest(a=a, b=b):
                self.assertEqual(add(a, b), expected)

What `subTest` gives you

All failures reported. Without subTest, the first assertEqual failure stops the loop. With it, every iteration is independent — the runner reports all five failing pairs at once.
Labelled failures. The kwargs you pass (a=a, b=b) appear in the failure message — you immediately see which input broke.
One test method, many cases. Easy to add cases — just append a tuple. Don't have to write a new method.

`pytest`'s version (for context)

Most real Python projects use pytest, which has a more concise version:

python

import pytest

@pytest.mark.parametrize("a, b, expected", [
    (1, 2, 3),
    (0, 0, 0),
    (-1, 1, 0),
])
def test_add(a, b, expected):
    assert add(a, b) == expected

Same idea, different syntax. Each tuple becomes a separate test. pytest is not available in our in-browser runtime; the subTest pattern works in pure stdlib.

When to parametrise

Same logic, many inputs. You're testing one function against a table of (input, expected) pairs. Parametrise.
Different logic, similar inputs. Don't parametrise — write separate test methods. Forcing them into one loop hides what each is checking.
Edge cases that need special setup. Don't parametrise — the setup variation will fight you. Write a separate test.

Where the cases come from

Good parametrised tests cover:

Happy path — the typical case (add(1, 2) == 3)
Boundaries — zero, empty, max (add(0, 0) == 0)
Negatives / errors — invalid input (add(-1, 1) == 0)
Past bug repros — every bug you've fixed, as a row in the table

The table grows over time. That's fine — it's the cheapest way to keep regressions caught.

Parametrising tests

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

When to parametrise

Where the cases come from

Parametrising tests

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

When to parametrise

Where the cases come from

Parametrising tests

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

When to parametrise

Where the cases come from

Sign up to practice

Parametrising tests

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

When to parametrise

Where the cases come from

Sign up to practice

Parametrising tests

subTest — the unittest pattern

What subTest gives you

pytest's version (for context)

When to parametrise

Where the cases come from

Parametrising tests

subTest — the unittest pattern

What subTest gives you

pytest's version (for context)

When to parametrise

Where the cases come from

Parametrising tests

subTest — the unittest pattern

What subTest gives you

pytest's version (for context)

When to parametrise

Where the cases come from

Sign up to practice

Parametrising tests

subTest — the unittest pattern

What subTest gives you

pytest's version (for context)

When to parametrise

Where the cases come from

Sign up to practice

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)

`subTest` — the `unittest` pattern

What `subTest` gives you

`pytest`'s version (for context)