Unit Test

Programs consist of many small building blocks. Each building block receives something and returns a result, for example the price including value-added tax. A unit test is a second, very small program that tries out exactly such a building block. It calls it with fixed values and compares the result with what should come out. If both match, the test counts as passed. If the result deviates, the test fails and reports the spot. The word “unit” refers to precisely this single building block.

The smoke detector for code

Software is constantly being changed. Someone adds a new feature or cleans up old code. In the process, something that worked before regularly breaks. Such errors are called regressions. Without tests, a regression often only comes to light weeks later, when a user complains.

Unit tests reverse this order. A project quickly accumulates several thousand of them. They run automatically with every change, often in under a minute. The developer thus sees the error while still knowing what they just did. That is the real benefit: finding errors early is many times cheaper than fixing them later in a running product.

A second effect is often underestimated. Anyone who knows that tests have their back is more willing to restructure confusing code. Without this safety net, much of it remains untouched for years, because nobody wants to bear the risk.

Structure of a single test

Almost every unit test has three steps. First, the starting situation is set up, for example a shopping cart with two items. Then the building block to be checked is called. Finally comes the assertion, as it is technically called: the result must be 23.80 euros. This assertion is written by the human, not the computer.

The boundary upward is important. A unit test only checks the one building block, not its interplay with a database or the internet. If the building block still needs a partner, it is replaced by a dummy, a so-called mock. This dummy delivers a fixed answer so that the test runs quickly and always the same way. Tests that check the real interplay, on the other hand, are called integration tests.

A common metric is test coverage. It states what proportion of code lines were actually run through during testing. A widespread misconception is that high coverage means error-free software. It only shows that code was executed, not that someone made meaningful assertions about it.

From the pipeline to the AI assistant

In almost every software company, unit tests run automatically on a server as soon as someone submits new code. This process is called continuous integration. If a test fails, the change is blocked and may not go into the product. On platforms like GitHub, you can see this in the green checkmarks and red crosses next to every contribution.

Unit tests are also playing a growing role in the AI world. Programming assistants like GitHub Copilot or Claude now write tests along on request. Conversely, tests serve as a touchstone for the models themselves: in benchmarks like SWE-bench, an AI must fix real bugs in open-source projects. A solution only counts as passed if all tests run through afterward. Here, the test is the neutral referee.

This becomes relevant for you yourself as soon as you write a project that lives longer than a weekend. Just ten good tests save a lot of searching when you look back into it after three months.