Test / Unit Test

How do you know the code you wrote still works, not just today, but after the next change, and the change after that? You don't recheck it all by hand every time. You write a test once and let it check for you, forever.

A test is a small piece of code whose only job is to run another piece of code and confirm it did the right thing. A unit test is the most common kind: it tests one small "unit," usually a single function, in isolation. Give it this input, confirm you get that output. If you do, the test passes. If you don't, it fails loudly and points right at what broke.

A smoke detector is the right mental model. You install it once and forget it. It sits there doing nothing, quietly, until the moment something's wrong, then it screams. A test is a smoke detector for one specific thing your code is supposed to do. You write it once, and from then on it watches that behavior for free, going off the instant someone breaks it, including future you.

Here's the part that makes it click for non-coders. The scary thing in software isn't writing new code, it's changing old code and not realizing you broke something three rooms away. You fix one thing and quietly snap something else that used to work. Tests are the defense. With a wall of them, you make your change, run the tests, and a green pass means "everything I had a test for still works." A red fail means "you just broke this, go look." (One honest limit: tests only watch what you point them at. Green means the things you test still work, not that nothing anywhere is broken. That's why a real safety net is a lot of good tests, not one.)

This is also the real reason tests matter so much when an AI writes your code. An AI can produce a lot of code fast, and it can confidently break things just as fast. Tests are how you keep it honest: the AI makes a change, the tests run, and if it broke something they cover, they catch it before you ship. Pairing an eval (for the AI's judgment) with tests (for the code's behavior) is how you move quickly without flying blind.

So "is it tested?" and "do the tests pass?" decoded: are there little tripwires confirming this actually works, and are they all still green? It's not bureaucracy. It's the thing that lets people change a big, scary codebase without holding their breath. Good tests are why a change can feel safe instead of terrifying.

A test is a tripwire you set once that screams the instant your code breaks, including when future you (or your AI) breaks it. It's how "I think it works" becomes "I checked, and what I test still does," and how anyone changes software without fear.