Unit- and Integration-testing

Plane photo

What is the difference between #unitTesting and #integrationTesting?

Is there any need for integration-testing?

Can Test Driven Development ( #TDD ) help to integration-testing or higher?


A unit is the smallest part of product. Imagine a “locked door” as a product, then the “lock” will be a unit and the “door” will be a unit:

Two units from a locked door

The “lock” can be unit-tested to make sure the it works as expected. The same goes for the “door”.


An integration-test validates if two or more units work together as expected:

Image source: https://twitter.com/codejobs/status/813056723271450624

When an integration-test finds a bug, it is often fixed by making changes to the unit – which is the wrong approach.

If an integration-test fails and is fixed within a unit, then the integration-test should have been a unit-test from the start.

I understand that not all errors can be caught through unit-testing and therefore integration-testing is important. But not all bugs need to be fixed on the unit-level, but can be fixed on the integration-level:

The lock can be moved to fix the problem

A question of clean architecture

We often over-complicate our products, by doing unit-testing, unit-integration-testing, system-testing, system-integration-testing, end-to-end-testing, etc…, while most of it could have been done as unit-testing.

We often think that a unit is the “smallest” part of a product, but actually a unit can be a product and a product can be a unit:

  • A lock can be a product consisting of multiple units (metal parts).
  • A lock can be a unit for a locked door.
  • A locked door can be a unit for a room.
  • A room can be a unit for a building.
  • A building can be a unit for a neighborhood.
  • Etc.

Our products should be split into architectural layers, where each layer assembles products from units (metal part -> lock -> locked door -> room -> building -> neighborhood -> etc…)


Maybe there is not need for integration-, system-, system-integration-testing., etc. Maybe it is all about unit-testing on multiple levels. We only need to split our products into clean layers, like the internet is split into theĀ OSI-layers.

We would be able to apply Test Driven Development on multiple layers and manage much higher complexity, that we normally wouldn’t be able to.

All Posts

Leave a Reply

Your email address will not be published.