A unit test is a small automated check that confirms one tiny piece of code, usually a single function, does exactly what it should. You give it a known input, state the expected output, and the test passes or fails in a fraction of a second. Run hundreds of them together and you get instant feedback on whether anything just broke.
Picture testing one light switch in a house before signing off on the wiring. You flip it and check the right bulb turns on, ignoring the rest of the building for now. A unit test is that single, focused check. For example, a test for a “calculate VAT” function feeds it 100 euros and confirms it returns 121, then feeds it 0 and confirms it returns 0. This sits one level below an integration test, which checks that many pieces cooperate.
Unit tests are the building blocks of the wider practice of unit testing. They are cheap to run, so developers run them constantly, and they pay off most when code changes later: if a small edit accidentally breaks the VAT calculation, a failing test points straight at it before any customer notices. A good one is also a tiny piece of documentation. It states, in plain code, what the function is supposed to do, so a new developer can read the tests to learn how a part is meant to behave. The aim is not to test everything. Chasing 100 percent test coverage wastes time on trivial code, while the tricky logic that actually breaks is where the focus belongs.
At TopDevs we write unit tests for the logic that really matters, like pricing and permissions, so a future change can never quietly corrupt the parts a client depends on.
