Academy — Sanjib Sikder

The Cost of Not Testing

Every program you write makes assumptions. This function always receives a positive number. That string is never empty. The list always has at least one item. These assumptions are invisible until they're wrong — and when they're wrong, something breaks, often in a way that's hard to trace back to the original assumption.

Testing is the discipline of making assumptions explicit and verifiable. A test is a piece of code that calls your code with known inputs and asserts that the outputs match what you expect. If they don't, the test fails immediately, loudly, and with a clear message.

This lesson uses Python's built-in unittest module — available everywhere, no installation needed.

Note: In a real development environment, you'd run tests from the command line with python -m unittest or using pytest, which discovers test files automatically. In this sandbox, we run the test suite directly by calling unittest.main() — the output is identical.

Your First Test

Python

Ctrl+Enter to run

import unittest

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

class TestAdd(unittest.TestCase):

    def test_positive_numbers(self):
        self.assertEqual(add(2, 3), 5)

    def test_negative_numbers(self):
        self.assertEqual(add(-1, -4), -5)

    def test_zero(self):
        self.assertEqual(add(0, 10), 10)

unittest.main(argv=[#22c55e">""], exit=False, verbosity=2)

The structure:

Test cases are classes that inherit from unittest.TestCase
Every test is a method that starts with test_ — the naming convention is how the runner finds them
self.assertEqual(actual, expected) checks that two values are equal. If not, the test fails with a clear message.
unittest.main(argv=[""], exit=False, verbosity=2) runs all tests and reports the results

verbosity=2 shows each test's name and result individually — useful for seeing exactly what ran.

The Assert Methods

unittest gives you specific assertion methods for different comparisons — each produces a more informative failure message than a raw assert:

Python

Ctrl+Enter to run

import unittest

class TestAssertions(unittest.TestCase):

    def test_equality(self):
        self.assertEqual(2 + 2, 4)
        self.assertNotEqual(2 + 2, 5)

    def test_boolean(self):
        self.assertTrue(5 > 3)
        self.assertFalse(5 < 3)

    def test_membership(self):
        self.assertIn(#22c55e">"apple", ["apple", "banana"])
        self.assertNotIn(#22c55e">"mango", ["apple", "banana"])

    def test_none(self):
        self.assertIsNone(None)
        self.assertIsNotNone(42)

    def test_approximate(self):
        self.assertAlmostEqual(0.1 + 0.2, 0.3, places=10)

unittest.main(argv=[#22c55e">""], exit=False, verbosity=2)

assertAlmostEqual is essential for floating-point comparisons — 0.1 + 0.2 is not exactly 0.3 in floating-point arithmetic, but it's close enough.

Testing for Exceptions

A function that should raise an exception under certain conditions needs to be tested for that too:

Python

Ctrl+Enter to run

import unittest

def divide(a, b):
if b == 0:
raise ValueError(#22c55e">"Cannot divide by zero.")
return a / b

class TestDivide(unittest.TestCase):

    def test_normal_division(self):
        self.assertEqual(divide(10, 2), 5.0)

    def test_negative(self):
        self.assertAlmostEqual(divide(7, 3), 2.333, places=3)

    def test_zero_denominator(self):
        with self.assertRaises(ValueError):
            divide(10, 0)

    def test_zero_numerator(self):
        self.assertEqual(divide(0, 5), 0.0)

unittest.main(argv=[#22c55e">""], exit=False, verbosity=2)

with self.assertRaises(ValueError): passes if the code inside raises a ValueError — and fails if it doesn't raise one (or raises a different exception). Testing that errors are raised correctly is just as important as testing that correct input produces correct output.

`setUp` and `tearDown`

When multiple tests share the same setup code, setUp runs before each test method — and tearDown runs after each one, regardless of whether the test passed or failed:

Python

Ctrl+Enter to run

import unittest

class ShoppingCart:
def **init**(self):
self.items = {}

    def add(self, item, price):
        self.items[item] = price

    def remove(self, item):
        del self.items[item]

    def total(self):
        return sum(self.items.values())

    def __len__(self):
        return len(self.items)

class TestShoppingCart(unittest.TestCase):

    def setUp(self):
        self.cart = ShoppingCart()
        self.cart.add(#22c55e">"notebook", 45)
        self.cart.add(#22c55e">"pen", 12)

    def test_initial_total(self):
        self.assertEqual(self.cart.total(), 57)

    def test_add_item(self):
        self.cart.add(#22c55e">"eraser", 8)
        self.assertEqual(len(self.cart), 3)
        self.assertEqual(self.cart.total(), 65)

    def test_remove_item(self):
        self.cart.remove(#22c55e">"pen")
        self.assertEqual(len(self.cart), 1)
        self.assertEqual(self.cart.total(), 45)

    def test_empty_after_removes(self):
        self.cart.remove(#22c55e">"notebook")
        self.cart.remove(#22c55e">"pen")
        self.assertEqual(self.cart.total(), 0)

unittest.main(argv=[#22c55e">""], exit=False, verbosity=2)

import unittest

class ShoppingCart:
def **init**(self):
self.items = {}

def add(self, item, price):
        self.items[item] = price

def remove(self, item):
        del self.items[item]

def total(self):
        return sum(self.items.values())

def __len__(self):
        return len(self.items)

class TestShoppingCart(unittest.TestCase):

def setUp(self):
        self.cart = ShoppingCart()
        self.cart.add("notebook", 45)
        self.cart.add("pen", 12)

def test_initial_total(self):
        self.assertEqual(self.cart.total(), 57)

def test_add_item(self):
        self.cart.add("eraser", 8)
        self.assertEqual(len(self.cart), 3)
        self.assertEqual(self.cart.total(), 65)

def test_remove_item(self):
        self.cart.remove("pen")
        self.assertEqual(len(self.cart), 1)
        self.assertEqual(self.cart.total(), 45)

def test_empty_after_removes(self):
        self.cart.remove("notebook")
        self.cart.remove("pen")
        self.assertEqual(self.cart.total(), 0)

unittest.main(argv=[""], exit=False, verbosity=2)

Each test method starts with a fresh cart containing notebook and pen. Tests are completely independent — one test's actions don't affect another's. This isolation is fundamental: a failing test should point to exactly one problem, not a cascade of side effects.

What Happens When a Test Fails

Python

Ctrl+Enter to run

import unittest

def is_palindrome(text):
    return text == text[::-1]

class TestPalindrome(unittest.TestCase):

    def test_simple(self):
        self.assertTrue(is_palindrome(#22c55e">"racecar"))

    def test_not_palindrome(self):
        self.assertFalse(is_palindrome(#22c55e">"hello"))

    def test_case_sensitive(self):
        # This will fail — our function is case-sensitive, "Racecar" != "racecaR"
        self.assertTrue(is_palindrome(#22c55e">"Racecar"))

unittest.main(argv=[#22c55e">""], exit=False, verbosity=2)

The failure message tells you exactly: which test failed, what was expected, and what was actually received. This is the feedback loop that makes testing valuable — not just "something is wrong" but "this specific expectation was not met."

The failing test has also revealed a real limitation: the function doesn't handle mixed case. You now know what to fix.

Test-Driven Development (TDD)

TDD inverts the usual order of work:

Write a test for behaviour that doesn't exist yet — it fails
Write the minimum code to make the test pass
Refactor the code without breaking the tests

Python

Ctrl+Enter to run

import unittest

# Step 1: Write the test first

class TestPasswordValidator(unittest.TestCase):

    def test_minimum_length(self):
        self.assertFalse(validate_password(#22c55e">"short"))

    def test_valid_password(self):
        self.assertTrue(validate_password(#22c55e">"SecurePass1!"))

    def test_no_uppercase(self):
        self.assertFalse(validate_password(#22c55e">"nouppercase1!"))

    def test_no_digit(self):
        self.assertFalse(validate_password(#22c55e">"NoDigitHere!"))

# Step 2: Write the function to pass the tests

def validate_password(password):
if len(password) < 8:
return False
if not any(c.isupper() for c in password):
return False
if not any(c.isdigit() for c in password):
return False
return True

unittest.main(argv=[#22c55e">""], exit=False, verbosity=2)

The tests define the specification. The function satisfies it. When requirements change — "passwords must also contain a special character" — you add a test first, watch it fail, then update the function. The existing tests confirm you haven't broken anything that was working.

This discipline changes how you think about code. Tests are not a chore added after writing — they are the design.

What You Have Learned

Testing turns invisible assumptions into explicit, verifiable statements — and makes every change to your code safe.

The key ideas:

Tests are code that calls your code and asserts expected behaviour
unittest.TestCase subclasses group related tests; methods starting with test_ are discovered automatically
Core assertions: assertEqual, assertTrue, assertFalse, assertIn, assertRaises, assertAlmostEqual
setUp / tearDown run before/after each test — use them to ensure test isolation
When a test fails, it reports exactly what was expected and what was received
TDD: write the test first, then the code — tests define the specification
Tests give you confidence to refactor and extend code without fear

You've Completed the Advanced Series

Thirty lessons across three tiers. From print("Hello, World!") to decorators, closures, async programming, NumPy arrays, Pandas DataFrames, and test-driven development.

You now have a complete, working knowledge of Python as it is used in the real world — in web development, data science, automation, scientific computing, and software engineering.

What comes next is practice, projects, and going deeper into the domains that interest you most. The language is now a tool you control. What you build with it is entirely up to you.

Testing

The Cost of Not Testing

Your First Test

The Assert Methods

Testing for Exceptions

setUp and tearDown

What Happens When a Test Fails

Test-Driven Development (TDD)

What You Have Learned

You've Completed the Advanced Series

`setUp` and `tearDown`