There seems to be confusion among
developers when referring to unit, integration and functional tests.
It makes it worst when these concepts are also used under different
names. The idea of this post is to define clearly these terms using
an authority on the field to remove the subjectiveness contra
argument.
I will use the definitions proposed by
Gerard Meszaros on the book “xUnit Test Patterns, Refactoring Test
Code”.
Unit Tests
Unit tests verify the behavior of a
single class or method that is a consequence of a design decision. This behavior is
typically not directly related to the requirements except when a key chunk of
business logic is encapsulated within the class or method in question. These
tests are written by developers for their own use; they help developers describe what
“done looks like” by summarizing the behavior of the unit in the form of
tests.
Integration Tests
Component tests verify components
consisting of groups of classes that collectively provide some service. They fit
somewhere between unit tests and customer tests in terms of the size of the SUT
being verified. Although some people call these “integration tests” or
“subsystem tests,” those terms can mean something entirely different from “tests of a
specific larger-grained subcomponent of the overall system.”
Functional Tests
Customer tests verify the behavior of the entire system or application. They typically correspond to scenarios of one or more use cases, features, or user stories. These tests often go by other names such as functional tests, acceptance tests, or end-user tests. Although they may be automated by developers, their key characteristic is that an end user should be able to recognize the behavior specified by the test even if the user cannot read the test representation.
Figure 6.1 A summary of the kinds of tests we write and why. The left column contains the tests we write that describe the functionality of the product at various levels of granularity; we perform these tests to support development.
The right column contains tests that span specific chunks of functionality; we execute these tests to critique the product. The bottom of each cell describes what we are trying to communicate or verify.
