These examples again demonstrate plain JUnit and Mockito test approaches. With some code quality practices, it's certainly possible to write maintainable, dense test cases with limited configuration overhead.

Component tests implemented as shown previously are a practical approach to wire up components that use straightforward dependency injection. If the production code makes use of CDI producers and qualifiers, the injection logic of the test components will change accordingly.

Component tests aim to verify the business use case behavior of coherent units. They usually don't verify the technical wiring. It's advisable to use integration tests in order to verify whether CDI injection was used correctly, for example, in terms of custom qualifiers, producers, or scopes.

However, there are test technologies that provide dependency injection into test cases. Examples for these are CDI-Unit or the more sophisticated Aquillian Testing Framework. Test cases using these frameworks run in containers, either embedded or even remotely, and are able to further verify the integration of components.

Sophisticated test frameworks certainly provide test cases that are closer to the enterprise application, but also come with the challenge of slow application startups. The containers are usually executed and configured in every test case, typically taking a few hundred milliseconds or more. This does not sound that much but quickly adds up as more tests arrive.

For component tests that aim to solely verify business behavior, faster, and lightweight approaches like the one presented, are therefore preferable. With their fast nature, component tests as well as unit tests are per default executed during the project build. They should be the default way how to verify application business logic.

The following shows code level integration tests that make use of simulated containers.