On many projects, unit tests are something you write just enough of to pass the coverage check in CI. A few test cases get written in a hurry, the pipeline turns green, and the code gets merged. But tests written to tick a box and tests written with a real understanding of their value are very different things, and that difference only shows as the project grows.
What a Unit Test Really Is
A unit test checks the smallest piece of code that can be isolated, usually a function or method, in isolation from the rest of the system. The goal isn't to prove the code "runs", it's to confirm the code behaves as expected for each type of input: normal cases, edge cases, and error cases.
Signs of Box-Ticking Tests
Box-ticking tests are usually easy to spot: they only check the "happy path" (clean input, correct result); they have no assertion that actually verifies the outcome and just call the function to raise coverage; they mock so heavily that the test is really only testing the mocks; or they have vague names like test1 or testFunction so nobody knows what behavior they protect.
High coverage built on tests like these creates a false sense of safety. The number says 90%, yet real bugs still slip through, because no test actually checks the behavior that matters.
The Real Value of Unit Tests
The biggest value of unit tests isn't catching bugs at the moment you write them, it's the future. First, tests let you refactor with confidence: when you restructure code, the test suite immediately tells you if behavior changed unintentionally. Without tests, every refactor is a gamble. Second, tests are living documentation: reading a function's tests often tells you how to use it faster than reading comments, and tests never go stale, because if they do, they fail. Third, tests catch bugs as early as possible, while they're still cheap to fix, instead of letting them reach staging or production.
One benefit rarely mentioned: code that's hard to test is often a sign of weak design, such as a function doing too much or depending tightly on too many other components. Writing tests forces you to look again at your own design.
Writing Tests That Mean Something
A few simple principles make tests genuinely valuable: name tests after the behavior they check, such as returns_zero_when_cart_is_empty instead of testCart; keep each test focused on one behavior; always cover edge cases and error cases, not just the happy path; only mock real external dependencies (databases, APIs, system time), never the logic you're trying to test; and keep tests fast so people are willing to run them often.
When tests are mandatory, many people treat them as paperwork. Once you understand why they matter, tests become a tool that helps you work faster and sleep better after every deploy.