Code level unit and component tests verify isolated, specific business logic. They provide immediate feedback and prevent careless mistakes. Component tests, in particular, cover the integration of business related software units.

The delimitation of component tests is that they run without a simulated container, setting up the test cases in a programmatic fashion. Integration tests rely on inversion of control, similar to application containers that wire up components with less developer effort involved. However, crafting maintainable test cases using a programmatic approach with unit test technology ultimately leads to more effective tests. We will see in the Maintaining test data and scenarios section in this chapter, what methods support us in crafting productive test cases.

Integration tests verify the technical integration as well as configuration of application components. Their feedback is certainly faster than deploying the application as part of the pipeline. However, integration tests do not provide sufficient verification compared to production.

They are a good fit to provide a first basic barrier against common errors and careless mistakes. Since starting up integration tests usually takes quite some time, it makes a lot of sense to run a limited number of them. Ideally test frameworks such as Arquillian deploy to managed or remote containers that keep running beyond a single test case.

System tests verify the application's behavior in the most production-like fashion. They provide the ultimate feedback, whether the whole enterprise application works as expected, including business as well as technical aspects. In order to construct predictable test scenarios, it's important to consider external concerns, such as databases and external systems.

Crafting test cases, especially complex test scenarios, takes a lot of time and effort. The question is where does it make the most sense to spend this effort on? In order to test business logic, and especially coherent components, it's advisable to use component tests. Integration tests don't provide ultimate verification, but still take certain time and effort. It makes sense to use a few of them for fast integration feedback, but not to test business logic. Developers may also find ways to reuse created scenarios in several test scopes, for example both integration tests and system tests.

The overall goal should be to minimize the time and effort spent to craft and maintain test cases, to minimize the overall pipeline execution time and to maximize the application verification coverage.