Unit- and Integration-testing
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?
Unit-testing
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:
The “lock” can be unit-tested to make sure the it works as expected. The same goes for the “door”.
Integration-testing
An integration-test validates if two or more units work together as expected:
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:
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…)
Reflection
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.