Integration Testing in Spring Boot

Integration Testing in Spring Boot ensures that different parts of your application work together correctly. Unlike unit tests that check individual classes, integration tests verify end-to-end behavior within the real Spring context and infrastructure (or controlled substitutes).

It helps confirm that your app behaves like it will in production, catching real-world issues before they reach users.

---

What Is Integration Testing?

Integration Testing checks whether multiple components of your Spring Boot application work correctly together.

It validates:

• Spring bean wiring & configuration
• Data flow between layers (Controller → Service → Repository)
• Serialization and deserialization
• Database persistence
• Security and transactions

Integration tests ensure your application is tested as a complete working system, not just isolated classes.

---

Why Integration Testing Is Important

Most real bugs happen between components, not inside a single class. Integration testing helps to:

• Detect issues missed by unit tests
• Validate database and API interactions
• Catch serialization/deserialization problems
• Find misconfigured beans or properties
• Ensure production-like behavior
• Prevent runtime and deployment failures
• Reduce expensive production bugs

---

Integration Testing vs Unit Testing

Unit testing checks individual classes in isolation with mocks, making it fast. Integration testing checks multiple components together with the real Spring context and database for realistic behavior.

Feature	Unit Testing	Integration Testing
Scope	Single class	Multiple components
Dependencies	Mocked	Real (or partially mocked)
Database	Not tested	Tested with real or in-memory DB
Spring Context	Not loaded	Fully loaded
HTTP Calls	Not tested	Tested end-to-end
Speed	Very fast	Medium (slower due to context & DB)
Purpose	Validate logic in isolation	Validate interactions & full flow

---

Tools for Integration Testing in Spring Boot

Tool	Purpose
@SpringBootTest	Loads the full Spring application context
@AutoConfigureMockMvc	Enables REST API testing
MockMvc / WebTestClient	Perform HTTP request testing
Testcontainers	Run real databases or services in Docker
WireMock	Mock external HTTP APIs
H2 / PostgreSQL	Database integration testing
Embedded Kafka	Kafka messaging tests
RestAssured	Fluent and readable API testing

---

Spring Boot Test Setup

@SpringBootTest

@SpringBootTest loads the full Spring application context, making tests behave like production.

@SpringBootTest
classApplicationIT { }

• All beans are created
• Configuration is loaded
• Application behaves like in production

---

Testing Application Context Loading

@SpringBootTest
classContextLoadTest {
@Test
voidcontextLoads() { }
}

• Detects missing beans
• Catches configuration issues early

---

Test Profiles (application-test.yml)

Use test-specific profiles to isolate test configuration from production.

spring:
datasource:
url:jdbc:h2:mem:testdb

@ActiveProfiles("test")
@SpringBootTest
classUserServiceIT { }

• Runs tests with separate test configuration
• No impact on production settings
• Ensures clean, isolated environment for each test

---

Integration Testing with Databases

Integration testing with databases ensures that your data layer works correctly with the application. It verifies repository queries, transactions, relationships, and persistence in a realistic environment.

H2 vs Real Database

Aspect	H2 (In-Memory)	Real Database (PostgreSQL/MySQL)
Speed	Very fast	Slower than H2
Environment	In-memory, ephemeral	Real SQL engine, production-like
Accuracy	Less accurate, may not match all SQL behavior	Fully accurate, matches production behavior
Use Case	Quick unit-level or integration tests where exact SQL behavior isn’t critical	Critical integration tests, transaction validation, and production-like queries

Prefer Testcontainers for critical database paths.

---

@DataJpaTest

@DataJpaTest is used for repository-focused integration testing with the database.

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;

@DataJpaTest
class UserRepositoryIT {

    @Autowired
    private UserRepository repository;

    @Test
    void shouldSaveUser() {
        // Create a new User entity
        User user = new User("Alice");

        // Save entity to database
        User saved = repository.save(user);

        // Verify the entity was persisted
        assertNotNull(saved.getId());
    }
}

• Repository + database
• No controllers/services needed

---

Transaction Rollback Behavior

Use @Transactional in Spring Boot tests to automatically roll back database changes after each test. This keeps tests isolated and the database clean.

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

@SpringBootTest
@Transactional
class OrderIT {

    @Test
    void shouldCreateOrder() {
        // Example: create and save an order
        Order order = new Order("Order001");
        Order saved = orderRepository.save(order);

        // Verify it is persisted
        assertNotNull(saved.getId());
    }
}

• Each test runs in a transaction
• Auto-rollback after test completes

---

Testing Custom Queries

Integration tests can validate:

• Verify JPQL and native SQL queries
• Check indexes, constraints, and relationships
• Ensures database logic works as expected

---

Controller Integration Testing

@SpringBootTest + MockMvc

@SpringBootTest
@AutoConfigureMockMvc
classUserControllerIT {
@Autowired
private MockMvc mockMvc;

@Test
voidshouldReturnUser()throws Exception {
        mockMvc.perform(get("/users/1"))
               .andExpect(status().isOk())
               .andExpect(jsonPath("$.id").value(1));
    }
}

• Tests full HTTP request → response
• Uses real controller and service
• Validates JSON serialization

Key Validations

• HTTP status codes
• Response headers
• JSON structure
• Request validation & error handling

---

Service Layer Integration Testing

Tests business logic + repository together without mocks. Ensures transactions, validation rules, and error handling work end-to-end.

Service + Repository Together

@SpringBootTest
classPaymentServiceIT {
@Autowired
private PaymentService service;

@Test
voidshouldProcessPayment() {
Paymentresult= service.process(100);
        assertEquals("SUCCESS", result.getStatus());
    }
}

• Business logic + database persistence
• No mocks required

@Transactional in Service Tests

• Ensures clean database state
• Prevents data leakage
• Keeps tests isolated

End-to-End Business Logic Testing

Integration tests verify:

• Validation rules
• Transaction behavior
• Edge cases
• Error handling

---

Using Testcontainers for Integration Tests

Testcontainers lets you run real infrastructure in Docker during integration tests, giving production-like behavior without affecting shared environments.

Supports:

• Databases: PostgreSQL, MySQL
• Caching: Redis
• Messaging: Kafka
• Other services: MongoDB

Example: PostgreSQL Container

@Testcontainers
@SpringBootTest
classOrderRepositoryIT {
@Container
static PostgreSQLContainer<?> postgres =newPostgreSQLContainer<>("postgres:15");
}

• Runs a real database
• Behaves like production
• Isolated environment

Dynamic Property Injection

@DynamicPropertySource
staticvoidproperties(DynamicPropertyRegistry registry) {
    registry.add("spring.datasource.url", postgres::getJdbcUrl);
}

---

Configuration & Profile-Based Testing

@ActiveProfiles

Use @ActiveProfiles to load environment-specific configurations during tests.

@ActiveProfiles("test")
@SpringBootTest
classConfigIT { }

• Environment-specific beans
• Keeps test configuration separate from production

Conditional Beans with Profiles

@Profile("test")
@Bean
DataSourcetestDataSource() { ... }

• Enables clean separation of environments
• Ensures safe, isolated configuration for testing

---

Common Integration Testing Pitfalls

Context Loading Failures

• Occurs when Spring fails to start the application context.
• Often due to missing beans, wrong profiles, or circular dependencies.

Slow Tests

• Tests take longer than expected.
• Caused by too many @SpringBootTest or heavy Docker/Testcontainers setups.

Data Leakage Between Tests

• One test affects another due to shared database or missing transactions.
• Can lead to inconsistent test results.

Flaky Tests

• Tests pass or fail randomly.
• Usually caused by hard-coded ports, timing issues, or order dependencies.

---

Best Practices

When NOT to Use Integration Tests

• Avoid for simple utility classes, pure logic, or edge-case algorithms.

Use unit tests for faster and isolated testing.

Naming Conventions

• Use clear, consistent names like UserServiceIT, OrderControllerIT, PaymentRepositoryIT for easier identification.

Parallel Execution Tips

• Keep tests isolated by avoiding shared database state.
• Use Testcontainers for separate environments.
• Use random ports to prevent conflicts.
• Ensure test data does not overlap between parallel runs.

---

Conclusion

Integration Testing in Spring Boot ensures your app works as a whole, not just in parts.

It checks:

• Spring configuration & bean wiring
• Layer interactions (Controller → Service → Repository)
• Database, HTTP, and serialization
• Security & transactions

Benefits: catch real bugs, boost confidence, stabilize releases, complement unit & E2E tests.