As you can see, the majority of tests in an application are usually tests that cover units of
code. A unit can be a single method, the most basic feature. Because of this scope, these
type of tests are called unit tests . They can be defined as tests written by a programmer to
verify that a relatively small piece of functionality is doing what it is intended to do. Be-
cause the unit is rather small, the number of these tests increases rapidly, so they become
the fundament of application testing appearing on the lowest level of the pyramid.
The next type of tests concerns bigger areas of code. They cover whole services or busi-
ness features. This means they cover multiple units of code and concern different modules
and libraries. The number of such tests would be lower than the number of unit tests. This
type of test is often called an integration test . Integration tests are done to demonstrate
that different pieces of the system work together; since they cover entire applications, they
require much more effort to be put together. For example, they usually require resources
such as database instances and hardware to be allocated for them. Integration tests do a
more convincing job of demonstrating how the system works (especially to nonprogram-
mers); at least to the extent that the integration test environment resembles the production
The last type of tests are UI tests, which can also be called acceptance tests. Their number
is the smallest in the project; they are usually the most troublesome to write to simulate
the user interacting with the application. They cover whole requirements and features.
Let's leave the topic of nonfunctional tests. For now, you have to only remember that they
can cover topics related to performance, security, and so on.
Search WWH ::