At this moment, you might be wondering whether unit testing could provide a solution for all your testing needs. Unfortunately, that is not the case. While unit tests usually cover the biggest percentage of your testing needs, functional and integration tests should be an integral part of your testing toolbox.

We'll cover other types of tests in more detail in later chapters. For now, a few important distinctions between them are as follows:

• Unit tests try to verify small units of functionality. In the Java world, those units are methods. All external dependencies, such as invocations of other classes and methods or database calls, should be done in memory with the use of mocks, stubs, spies, fakes, and dummies. Gerard Meszaros coined a more general term, test doubles, that envelops all those (http://en.wikipedia.org/wiki/Test_double). Unit tests are simple, easy to write, and fast to run. They are usually the biggest percentage of a testing suite.
• Functional and acceptance tests have a job to verify that the application we're building works as expected, as a whole. While those two differ in their purpose, both share a similar goal. Unlike unit tests that are verifying the internal quality of the code, functional and acceptance tests are trying to ensure that the system is working correctly from the customer's or user's point of view. Those tests are usually smaller in number when compared with unit tests due to the cost and effort needed to both write and run them.
• Integration tests intend to verify that separate units, modules, applications, or even whole systems are properly integrated with each other. You might have a frontend application that uses backend APIs that, in turn, communicate with a database. The job of integration tests would be to verify that all three of those separate components of the system are indeed integrated and can communicate with each other. Since we already know that all the units are working and all functional and acceptance tests are passed, integration tests are usually the smallest of all three as their job is only to confirm that all the pieces are working well together:

The testing pyramid states that you should have many more unit tests than higher-level tests (UI tests, integration tests, and so on). Why is that? Unit tests are much cheaper to write, faster to run, and, at the same time, provide much bigger coverage. Take, for example, registration functionality. We should test what happens when a username is empty, when a password is empty, when a username or password is not in the correct format, when the user already exists, and so on. Only for this single functionality there can be tens, if not hundreds of tests. Writing and running all those tests from the UI can be very expensive (time-consuming to write and slow to run). On the other hand, unit testing a method that does this validation is easy, fast to write, and fast to run. If all those cases are covered with unit tests, we could be satisfied with a single integration test that checks whether our UI is calling the correct method on the backend. If it is, details are irrelevant from an integration point of view since we know that all cases are already covered on the unit level.