What is Integration Testing in Java?

Integration testing in Java is a testing method that verifies whether different modules or components of an application, such as controllers, services, repositories, and external APIs, work correctly when combined. It runs after unit testing and before system testing, catching defects like data-format mismatches, broken database schemas, and failing third-party calls that isolated unit tests miss. In Java, integration tests are typically written with JUnit, TestNG, and Spring Boot Test.

Understanding Integration Testing in Java

A unit test proves that one class does its job in isolation, usually by mocking everything around it. That is valuable, but real bugs often hide in the seams between components, where a service passes data to a repository or a controller calls a downstream API. Integration testing exists to exercise exactly those seams. It confirms that the pieces you already unit-tested still behave correctly once they are wired together and talking to real (or realistically simulated) dependencies.

In the Java ecosystem this usually means loading part or all of the Spring application context, connecting to a database, and asserting on the end result of a full request rather than a single method return value. For a broader, language-agnostic explanation of the discipline, see the integration testing guide in our Learning Hub. Java simply gives you a mature toolset, JUnit, Spring Boot Test, and Testcontainers, to implement it cleanly.

Why Integration Testing Matters in Java

Modern Java applications are rarely monolithic in behavior. A single feature may span a REST controller, a business service, a JPA repository, a caching layer, and one or more third-party integrations. Any of those boundaries can fail even when every individual unit passes its tests. Integration testing is what gives teams confidence that the assembled system actually works.

• Catches interface defects: mismatched request/response formats, wrong serialization, and incorrect HTTP status codes surface here rather than in production.
• Validates data flow: confirms that data written through a service is persisted and read back correctly through the real persistence layer.
• Reduces technical debt: issues found at the integration stage are far cheaper to fix than those found after release.
• Builds release confidence: a green integration suite in CI is a strong signal that a merge is safe to deploy.

Types of Integration Testing Approaches

There are four widely used strategies for combining and testing modules. Choosing one depends on how your application is layered and how much of it is ready at test time.

• Big-bang approach: all modules are integrated at once and tested as a complete system. It is fast to set up but makes pinpointing the source of a failure difficult.
• Top-down testing: higher-level modules are tested first, with lower-level modules replaced by stubs, then the hierarchy is filled in layer by layer.
• Bottom-up testing: low-level modules are built and tested first using drivers, then progressively combined into higher layers.
• Sandwich (hybrid) testing: top and bottom layers are tested in parallel and meet in the middle, giving combined coverage on larger systems.

A closely related, larger-scope discipline is system integration testing, which validates entire systems and services working together rather than modules inside a single application.

How to Perform Integration Testing in Java

The most common modern approach uses JUnit 5 with Spring Boot Test. The workflow is: define the scope, boot the application context, exercise a real endpoint, and assert on the outcome. The example below uses @SpringBootTest with a random port and MockMvc to test a controller together with its service and repository.

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@SpringBootTest
@AutoConfigureMockMvc
class UserControllerIntegrationTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void shouldReturnUserFromDatabase() throws Exception {
        // Hits the controller, which calls the real service and repository
        mockMvc.perform(get("/api/users/1"))
               .andExpect(status().isOk())
               .andExpect(jsonPath("$.name").value("Ada Lovelace"));
    }
}

Here nothing is mocked between the controller and the database, so the test proves the whole flow works. To make the test fully self-contained, pair it with Testcontainers so the database is a real, disposable Docker instance rather than an in-memory substitute:

@SpringBootTest
@Testcontainers
class OrderRepositoryIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:16");

    @DynamicPropertySource
    static void configure(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Autowired
    private OrderRepository orderRepository;

    @Test
    void savesAndReadsOrder() {
        Order saved = orderRepository.save(new Order("SKU-42", 3));
        assertThat(orderRepository.findById(saved.getId())).isPresent();
    }
}

For a deeper walkthrough of Spring-specific setup and annotations, our complete guide to Spring testing covers slices like @DataJpaTest and @WebMvcTest in detail.

Popular Tools and Frameworks for Java Integration Testing

• JUnit 5 / TestNG: the test runners that execute your integration scenarios and manage lifecycle, fixtures, and assertions.
• Spring Boot Test: provides @SpringBootTest, MockMvc, and test slices to load and drive the application context.
• Testcontainers: spins up real databases, message brokers, and services in Docker for high-fidelity tests.
• WireMock: stubs and simulates external HTTP APIs so tests stay deterministic and offline.
• Mockito: mocks the specific collaborators you deliberately want to keep out of scope.
• Maven / Gradle: orchestrate the suite, separate integration tests from unit tests, and run them in CI.

If you plan to also validate the front end that sits on top of these services, our Java automation testing platform lets you run Selenium and other Java tests at scale in the cloud.

Best Practices for Java Integration Testing

• Keep them separate: tag or name integration tests distinctly (for example *IT.java) so they can run separately from fast unit tests.
• Prefer real dependencies over mocks: use Testcontainers for databases instead of H2 where behavior differs, so tests reflect production.
• Reset state between tests: use transactions or clean-up hooks so tests are independent and repeatable.
• Test early and in CI: run integration tests on every merge to catch broken interfaces quickly.
• Cover realistic scenarios: validate each integration point with data that resembles production, including edge cases.

Common Mistakes and Troubleshooting

• Over-mocking: mocking the very dependencies you are supposed to integrate turns an integration test back into a unit test that proves nothing about the seams.
• Shared mutable state: tests that leave data behind cause flaky, order-dependent failures. Roll back or clean up after each test.
• Booting the whole context needlessly: using @SpringBootTest everywhere slows the suite. Use test slices such as @DataJpaTest when only the persistence layer matters.
• Ignoring environment parity: passing against an in-memory database but failing on real PostgreSQL means the test environment did not match production. Prefer Testcontainers.
• No timeouts on external calls: unstubbed network calls make tests slow and non-deterministic. Stub them with WireMock.

Running Java Integration Tests Across Real Browsers and Devices

Integration testing does not stop at the service layer. Once your Java back end is verified, the UI that consumes those APIs must behave consistently across browsers and devices. With TestMu AI you can run Java-based Selenium and end-to-end integration suites across 3000+ real browsers, operating systems, and devices in the cloud, without maintaining your own grid. Running the same suite on the real device cloud and through automation testing in parallel shrinks feedback time and surfaces environment-specific failures that a single local machine would never reproduce.

Conclusion

Integration testing in Java bridges the gap between isolated unit tests and full system testing by proving that modules actually cooperate. With JUnit, Spring Boot Test, and Testcontainers you can exercise real controllers, services, databases, and APIs, choosing an approach, big-bang, top-down, bottom-up, or sandwich, that fits your architecture. Combine solid back-end integration tests with cross-browser and cross-device coverage on TestMu AI, and you get a testing strategy that catches defects early and ships reliable software with confidence.

Frequently Asked Questions

What is the difference between unit testing and integration testing in Java?

Unit testing verifies a single class or method in isolation, usually with mocks standing in for collaborators. Integration testing verifies that multiple modules, such as a controller, service, and repository, work together correctly, often with a real database or the Spring context loaded, so the seams between components are actually exercised.

Which tools are used for integration testing in Java?

The common stack is JUnit 5 or TestNG as the runner, Spring Boot Test with @SpringBootTest and MockMvc for driving the app, Testcontainers for real databases in Docker, WireMock for stubbing external APIs, and Maven or Gradle to organize and execute the suite in CI.

What is @SpringBootTest used for?

@SpringBootTest boots the full Spring application context for a test, wiring real beans together instead of mocks. It is the standard way to write integration tests in Spring Boot and can start an embedded web server on a random port so you can test complete HTTP request-and-response flows end to end.

Is JUnit used for integration testing?

Yes. Although JUnit is best known for unit testing, it is also the runner for most Java integration tests. Paired with Spring Boot Test, Testcontainers, or MockMvc, JUnit executes integration scenarios that span several layers of the application in a single test run.

When should integration testing be performed in Java?

Integration testing runs after unit testing and before system testing. In modern CI pipelines it executes on every merge so that broken interactions between services, databases, or APIs are caught early, well before the code reaches a production environment.

What is a common approach to integration testing in Java?

The four main approaches are big-bang, top-down, bottom-up, and sandwich (hybrid) integration. Incremental strategies like top-down and bottom-up are generally preferred because they make it much easier to isolate the exact interface where a defect appears.

• What is API integration testing?
• What is system integration testing?
• What is continuous integration testing?
• How does integration testing lead to continuous deployment?
• What is Cucumber?