Let me guess — you’ve heard “you should write tests” more times than you can count, and you’ve nodded along and then gone back to clicking through your browser to check if things work.

I get it. I was there too.

So what is unit testing?

Unit testing means writing simple code to test code you’ve already written. You pick a function, you define what it should do, and you write an assertion that confirms it does exactly that. That’s it.

import unittest

def add_one(n):
    return n + 1

class TestAddOne(unittest.TestCase):
    def test_add_one(self):
        self.assertTrue(add_one(4) == 5)

Not scary. Five lines.

Without tests vs. with tests

Without tests, your workflow looks like this: make a change, run the server, open the browser, navigate to the right page, check if it works, repeat.

With tests: make a change, run tests, read the result. Done. You don’t even need a browser open.

The other thing nobody tells you — writing tests while you write code (TDD) is faster than writing them after. Adding tests to a finished project is painful. Adding tests as you go is just part of the flow.

The excuses

I’ve heard all of them. Here are the three most common:

“That’s what QA is for.” QA catches bugs in your output. Tests improve the quality of your code itself. These are different things.

“Writing tests takes too long.” The time you spend debugging production issues without tests is longer. Much longer.

“I’m a good enough developer that I don’t need them.” I’ve thought this. Everyone who’s shipped a critical bug at 2am has thought this. Problems have a way of finding exactly the gaps in your confidence.

Start small. Write one test. Then another. It compounds.