What Is Unit Testing?
A unit test verifies the smallest meaningfully testable unit of software in isolation from the rest of the system: a function, a method, a class or a module. The same test level also runs under the names component testing and module testing; all three terms describe the same concept. The ISTQB defines component testing as “a test level that focuses on individual hardware or software components”. In everyday project language, unit test is the term that stuck. I cannot remember a single project in the last 25 years where this test level was called anything else.
Developers write their unit tests themselves, usually with a test framework such as JUnit, pytest or NUnit. The tests run automatically with every change to the code, and that is exactly where their value comes from: unit testing is the fastest feedback mechanism in software development. If you change or extend the code, you see immediately whether you have just broken something.
Unit tests are also an excellent indicator of the quality of architecture and design. A “you can’t unit test this” strongly suggests that trouble is lurking in that spot: too many dependencies, units too large, coupling too tight. By the time that area gets refactored, the safety net of tests will be missing. The same goes for execution time: unit tests have to run fast. If they cannot, that is another reason to take a second look at how the units are cut.
Positioning within the Test Levels
Unit testing is the lowest of the classical test levels, before integration testing, system testing and acceptance testing. Each level catches the defects that originate on its own layer. For unit testing, these are defects in the inner logic of a unit: wrong calculations, sloppy boundary handling, unhandled exceptions.
This position makes it the cheapest of all test levels. A bug that shows up in a unit test sits close to the code and is usually located quickly. The same bug costs a multiple in system testing, because it first has to be traced back through several layers. And without sufficient unit tests, stable integration, system and acceptance tests are hard to achieve: unstable behaviour on the upper levels almost always points back to missing robustness at the very bottom.
Unit Test vs. Integration Test
A unit test checks one unit on its own; an integration test checks how several units work together across their interfaces. For a unit to be tested in true isolation, stubs and mocks replace its dependencies: they simulate the calls and responses of the neighbouring components. The whole validity of the test hangs on this isolation. If a test does not run in isolation, it tests the dependencies along with the unit, and then nobody can say where a defect actually sits.
| Unit test | Integration test | |
|---|---|---|
| Test object | a single function, class or module | interplay of several components |
| Focus | inner logic of the unit | interfaces and data exchange |
| Dependencies | replaced by stubs and mocks | real or partially simulated |
| Test basis | component specification, design, code | architecture, interface specifications |
| Typical defects | calculations, boundaries, exceptions | data formats, call sequences, error propagation |
| Execution time | milliseconds to seconds | noticeably slower |
| Responsibility | development | development, at higher levels also test teams |
Two more levels follow further up: system testing evaluates the complete system against its specified requirements, and acceptance testing judges from the customer’s perspective whether the system is fit for use. None of these levels replaces another. They answer different questions.
Objectives of Unit Testing
The objective of unit testing is to verify functional and also non-functional aspects at the lowest level. The other test levels and the entire architecture build on well-tested units. Defects surface close to the code and can be fixed there quickly and precisely. And every change to the software gets immediate feedback on whether existing behaviour still holds.
That last point grows more valuable over time. Software without unit tests grows quickly at first. As complexity rises, this reverses: every change becomes a risk, because nobody can say with confidence what it triggers elsewhere. Unit tests keep the code changeable over the years.
Test Basis
The test basis for unit testing consists of all the information that describes the small functional block: details derived from design or architecture, parts of a user story or requirement, sometimes component specifications or models. And the source code itself, when it comes to structure-based test cases and the coverage of branches and conditions.
Test Case Derivation
The structured test design techniques suit this level particularly well: equivalence partitioning, boundary value analysis, decision tables, plus combinatorial approaches such as pairwise testing or the classification tree. Compared to system or acceptance testing, there is one tangible advantage here: value ranges, data types and conditions are far more concrete, which makes deriving test cases easier.
Negative tests deserve special attention. A unit test that only covers the standard case says little about how the unit behaves with corrupt data, boundary values or parameters outside the specification. Yet that is exactly where the defects sit that become expensive later.
What Makes a Good Unit Test?
A good unit test is fast, independent of other tests, repeatable with the same result every time, and evaluates itself: it is green or red, no human has to interpret log files. In the clean code community, these properties are known as the FIRST principles (Fast, Independent, Repeatable, Self-validating, Timely).
Readability comes on top. A unit test checks one aspect, carries a descriptive name and follows a clear structure: set up, execute, verify (Arrange, Act, Assert). This way the tests double as documentation. Anyone who wants to know how a class is meant to be used reads its tests.
Test Driven Development (TDD)
Agile software development has made Test Driven Development popular as a way of working in unit testing. It reverses the order: the test is written first and fails. Then you write the functional code until the test turns green. Then you clean up. Development continues in this rhythm.
TDD has many advantages. The focus on tests is built in rather than bolted on, and the code is cut for testability from the start, which shows directly in the architecture. TDD also has limits: it demands discipline, and not every task suits it equally well; exploratory work on an unclear problem less so than the implementation of clearly specified logic. TDD is a tool, not an obligation. Master it and you have one more option.
Code Coverage in Unit Testing
With unit tests, the topic of code coverage comes up almost every time. Code coverage shows how much of the source code is executed when the tests run. Depending on which parts you measure, you distinguish statement coverage and branch coverage, among others.
Coverage is often used as an exit criterion or definition of done: “unit tests must reach 80% code coverage.” Defining and measuring such numbers is interesting in itself. But it creates a serious problem: the quality of the test cases can drop, because coverage gets chased with the simplest possible tests. Special cases and negative tests fall away, since they barely raise the number. One hundred percent coverage with weak tests is worth less than seventy percent with good ones.
Such benchmarks should therefore be treated with caution. They can raise awareness for unit testing, but they can just as easily breed negligence. Coverage is a diagnostic tool that makes gaps visible. As a target figure, it is of limited use.
Test Environment
There are usually two environments for unit tests: the development environment, where the tests run quickly and without ceremony, and the build server or CI pipeline, where they run automatically with every commit. For both, a broad range of tools and well-worn routines exists.
Since unit tests concentrate on one unit at a time, one question remains: what happens to the rest, the calling and the called classes? These are typically replaced by test drivers, stubs and mocks that simulate the necessary calls and responses.
Test Data
Thanks to the small scale of unit tests, handling test data is usually manageable. The data only needs to cover one specific aspect and is easy to set up and tear down. It lives either directly with the test cases or in a shared repository. In larger projects a test data generator can be worth it, above all for edge cases and special constellations that would be tedious to maintain by hand.
Test Automation in Unit Testing
Test automation is a no-brainer for unit tests. Established frameworks exist for every common programming language: JUnit for Java, pytest for Python, NUnit for .NET, Jest or Vitest for JavaScript and TypeScript. They support writing and running the tests alike, in the development environment as much as in the build pipeline.
While every automation effort on the higher test levels involves weighing cost against benefit, that question does not arise here. A unit test that does not run automatically is hardly one at all: its value lies precisely in running along with every change, without anyone having to lift a finger.
Unit Tests in Agile Projects
Unit tests are necessary in all types of projects. In agile projects they have held a high standing from the beginning, because with continuous refactoring and short cycles, fast feedback is not negotiable. A team that ships every two weeks cannot manually re-verify the whole product before every release.
The test pyramid by Mike Cohn captures this: many fast unit tests at the base, fewer integration tests above them, a small number of end-to-end tests at the top. The distribution is not a dogma, but the core idea holds: the further down a defect is found, the cheaper it is.
Typical Problems
In projects, I keep running into three problems that need solving:
- Negative tests and special cases are missing. The unit tests then only show that the standard case works, but not what happens with corrupt data or parameters outside the specification.
- The focus is on functionality, and unit tests never get written. The tricky part: at first this works fine. The software is still manageable, everything runs, development progress is brilliant. In the background, though, a mountain of technical debt builds up that is hard to work off later.
- The necessity is not recognised. Statements like “I’m done, I just need to write the tests” show that unit tests are seen as a detached task. In high-performance teams, “done” only counts once all tests are written too. That is a different mindset, and in my experience it leads to markedly better results.
Limits of the Approach
Unit tests verify that a unit does what its developer intended. Whether that intention was right in the first place, they do not verify: a misunderstanding in the requirements travels into code and test alike. That takes the higher test levels and the comparison against the requirements.
The interplay of units also stays out of scope; that is the job of integration testing. And a warning from practice: mock too much and you end up testing mostly your mocks. When a test only verifies that simulated responses are passed through correctly, its value is close to zero.
From Practice
For me, unit testing is the most important of all test levels. It is the first thing I look at when I start a new consulting project, because this is where the robustness of an application shows. A minimum level of unit testing has arrived in practice, more so than at the other test levels. Yet implementation often falters: too often the focus sits purely on code coverage, or writing tests is treated as a necessary evil. And it is precisely at this level that so many quick wins for the project are up for grabs.