There is a lot of disagreement as to what integration tests represent and how they are designed. The aimed integration can happen on various levels.

I will use the term as it is quite widely used in the Java ecosystem and as it is represented in the Maven conventions. Integration tests run on code level, providing integration of several units and components, and usually run some more-or-less complex testing framework. This is the main distinction from component tests here.

Integration tests have a similar scope as component tests also integrate several units; however, the focus is on the integration. This integration is more technology than business related. For example, managed beans can make use of CDI injection to acquire certain dependencies using qualifiers or CDI producers. Developers need to verify whether the CDI plumbing has been done properly, that is, the correct annotations have been used, without necessarily deploying the application to a server.

Testing frameworks start up an embedded runtime that will build up several components and run code level tests against them.

Component tests, however, solely focus on the business logic and are limited to simple dependencies that are easily resolvable without sophisticated containers. In general, component tests are preferable for testing business use cases since they contain less moving parts and will run faster.