Unit test

A unit test exercises one small piece of behavior on its own: a function, a class, a module, whatever the smallest thing worth naming is. Hand it inputs, check what comes back. No HTTP, no real database, no clock you don't control. Collaborators get swapped for doubles you control, though how much you swap is a dial rather than a rule: enough that the test stays fast and deterministic, and no more.

Reach for them on logic worth pinning down: pricing math, date parsing, a reducer, validation rules, that one regex nobody trusts. They run in milliseconds, so you can keep thousands of them and still get an answer before you finish reading your own diff. Vitest, Jest, pytest, and Go's testing package all live at this layer.

Gotcha: a green wall of unit tests proves nothing about whether the pieces fit together. Fake everything and you end up testing your fakes. A red unit test narrows the search rather than ending it, because the fault can just as easily sit in the setup or in a double that drifted away from the real thing. And if a 'unit' needs six mocks just to stand up, that's a design problem wearing a testing costume.