There are many different types of testing, and unfortunately, there isn’t a clean line between the different definitions. Often, on forums like StackOverflow, there are questions asking something like, “What makes a test a unit test vs integration test?”
The short answer to these questions is usually, “Well, it depends on where exactly you draw the line between different types of testing.” The important thing is that within your team or organization, you have a clear definition that avoids any potential confusion or conflict.
With that said, here are the characteristics that generally describe different types of testing:
This is testing the smallest testable part of the code base. In Java, you could consider a standalone method within a class as a unit, or you could consider the class itself as the unit. There certainly should not be any interaction with services outside of the product (e.g. Databases, Kafka, Web Servers). These would typically be stubbed or mocked.
Unit tests often have a huge overlap with component testing.
This is testing a single component of the solution. Typically, in Java, a module would be considered a component. The focus is on whether the component delivers the required functionality for the rest of the solution. It should not rely on other modules, as these would typically be mocked or stubbed.
Testing the interaction between two or more components in the product. One of the key parts of an integration test is that it is testing, or relying on, the actual behavior of an interface between two components. Essentially, unlike component or unit testing, a change in either component can cause the test to fail.
This is testing the entire solution as the user is expected to use the system. The testing should be done via the user interface. This will most likely involve the use of specific automation tools, such as Selenium, for interacting with a Web UI.
Typically used by a client or a stakeholder, acceptance testing is a set of tests that prove the product is suitable for its intended use. Acceptance tests are often also end-to-end tests, but with the specific purpose of preventing the release or handover of a solution if they fail.
Check out our Definitive Guide to Unit Testing:
- Chapter 1: How to write your first unit test
- Chapter 2: How to measure code coverage
- Chapter 3: How to build a complete test suite
- Chapter 4: Mocking in unit tests
- Chapter 5: Finding the time and motivation to unit test
- Chapter 6: Unit testing mistakes to avoid
- Chapter 7: How automated unit tests speed up continuous integration
- Chapter 8: How to deliver on the promises of DevOps
- Chapter 9: Why imperfect tests are better than no tests