Top 8 Senior Interview Questions

Direct answer

The test pyramid says: many unit tests at the base, fewer integration tests in the middle, very few E2E tests at the top. The reasoning is cost — unit tests are fast, cheap, and pinpoint failures precisely. E2E tests are slow, brittle, and when they fail you often don't know where to look.

In practice on Spring Boot services, I aim for roughly: 70% unit, 25% integration, 5% E2E. But the exact ratio matters less than making sure each layer tests the right thing.

What each layer should own

• Unit tests — business logic in isolation. Service classes, domain objects, pure functions. No Spring context, no database, no network. Fast: should run in milliseconds.
• Integration tests — component boundaries. Does my repository actually write/read correctly? Does my REST controller serialize the response correctly? Does my Kafka consumer handle a malformed message? Real database via Testcontainers, partial Spring context.
• E2E tests — critical user journeys only. "Can a user place an order and receive a confirmation?" Not every endpoint — just the paths that, if broken, would cause an incident.

The anti-pattern I avoid

The inverted pyramid — teams that test almost everything through @SpringBootTest because "it's closer to production." These test suites take 20+ minutes to run, developers stop running them locally, and the feedback loop dies. I've seen this on multiple teams. The fix is always pushing logic down into pure service/domain classes that can be tested without a context.

Direct answer

These three annotations load different slices of the Spring context. Choosing the right one is about loading only what you need — smaller context = faster startup = faster feedback.

@SpringBootTest — full context

Loads the entire application context, exactly like production. Use it for true integration tests where you need multiple layers working together — controller + service + repository + database. It's the slowest option. If you use it for everything, your test suite will crawl.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class OrderFlowIntegrationTest {
    @Autowired TestRestTemplate restTemplate;

    @Test
    void placeOrder_fullFlow_returnsOrderId() {
        // hits real controller → service → repository → DB
    }
}

@WebMvcTest — controller slice only

Loads only the web layer: controllers, filters, Jackson config, Spring Security. No service beans, no repositories. Everything else you mock. Use it to test request mapping, input validation, serialization, and error handling — without needing a database.

@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @Autowired MockMvc mockMvc;
    @MockBean OrderService orderService;  // service is mocked — not loaded

    @Test
    void createOrder_invalidBody_returns400() throws Exception {
        mockMvc.perform(post("/orders")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{}"))
               .andExpect(status().isBadRequest())
               .andExpect(jsonPath("$.errors").isArray());
    }
}

@DataJpaTest — JPA slice only

Loads only JPA repositories, entity classes, and an in-memory H2 database by default. No web layer, no services. Use it to test custom JPQL queries, derived query methods, and entity mappings. I usually override the database with Testcontainers to avoid H2/PostgreSQL dialect differences:

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) // use real DB
@Import(TestcontainersConfig.class)
class OrderRepositoryTest {
    @Autowired OrderRepository repo;

    @Test
    void findByCustomerIdAndStatus_returnsMatchingOrders() {
        // test your custom query against real PostgreSQL
    }
}

Quick decision rule

Direct answer

@Mock is pure Mockito — it creates a mock object with no Spring involvement at all. Use it in plain unit tests where you're not loading a Spring context. @MockBean is Spring Boot's wrapper — it creates a Mockito mock and registers it as a Spring bean, replacing any real bean of that type in the application context. Use it in slice tests like @WebMvcTest where Spring needs to inject the dependency.

@Mock — plain unit test

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock OrderRepository repo;       // pure Mockito, no Spring
    @Mock PaymentClient paymentClient;

    @InjectMocks OrderService service; // Mockito injects mocks into constructor

    @Test
    void placeOrder_insufficientStock_throwsException() {
        given(repo.findAvailableStock(any())).willReturn(0);
        assertThatThrownBy(() -> service.placeOrder(order))
            .isInstanceOf(InsufficientStockException.class);
    }
}

@MockBean — Spring slice test

@WebMvcTest(OrderController.class)
class OrderControllerTest {

    @Autowired MockMvc mockMvc;
    @MockBean OrderService orderService; // replaces real bean in Spring context

    @Test
    void getOrder_notFound_returns404() throws Exception {
        given(orderService.getOrder(99L)).willThrow(new ResourceNotFoundException());
        mockMvc.perform(get("/orders/99"))
               .andExpect(status().isNotFound());
    }
}

When mocking hurts

Mocking gives you false confidence when you mock the wrong thing. The classic trap: you mock a repository, your service test passes, but in production the query is wrong or the transaction boundary is in the wrong place. The mock didn't test any of that.

My rule: don't mock what you own at the boundary. Mock external HTTP clients, third-party SDKs, email services. Don't mock your own repositories — use Testcontainers for those. The gap between your mock and reality is where production bugs live.

Direct answer

When you annotate a test method with @Transactional, Spring wraps the entire test in a transaction and automatically rolls it back after the test completes. This keeps the database clean between tests without you having to delete data manually. It's convenient — but it has a well-known trap that I always warn junior engineers about.

The rollback mechanism

@DataJpaTest  // @Transactional is applied by default in DataJpaTest
class OrderRepositoryTest {

    @Autowired OrderRepository repo;

    @Test
    void save_thenFind_returnsOrder() {
        repo.save(new Order("ORD-001"));
        assertThat(repo.findByReference("ORD-001")).isPresent();
        // after test: entire transaction is rolled back — DB is clean
    }
}

The trap — transactional tests hide real bugs

Your production code runs in separate transactions: the controller commits, then the next request reads. In a transactional test, everything is in one transaction that never commits. This hides three categories of bugs:

• LazyInitializationException — in the test, the session is open the whole time so lazy loading works fine. In production, the session closes after the transaction, and your code tries to access a lazy collection outside of it — exception.
• Unique constraint violations — constraints are only checked on commit in some databases. Your test never commits, so it never sees the violation.
• @Transactional(propagation = REQUIRES_NEW) — a method that opens a new transaction will actually commit in production. In your test, it still gets rolled back with everything else because the test transaction is the outermost one.

When to avoid @Transactional on tests

For integration tests that test transactional behaviour — like testing that a REQUIRES_NEW inner transaction commits independently, or that a constraint is enforced — don't use @Transactional on the test. Clean up manually or use Testcontainers with a fresh schema per test run instead.

@SpringBootTest
class OrderIntegrationTest {
    // No @Transactional — transactions behave exactly like production

    @Autowired OrderRepository repo;

    @AfterEach
    void cleanup() {
        repo.deleteAll(); // manual cleanup — more honest
    }
}

Direct answer

Testcontainers is a library that spins up real Docker containers — PostgreSQL, Redis, Kafka, whatever — as part of your test lifecycle. The container starts before your tests, your tests run against it, then it shuts down. You test against the exact same database engine you run in production.

H2 is an in-memory database that's fast and zero-config, but it's not the database you run in production. The SQL dialects differ, the constraint behaviour differs, the index behaviour differs. I've seen bugs that only appeared in production because H2 silently accepted SQL that PostgreSQL rejects.

Basic setup

@SpringBootTest
@Testcontainers
class OrderRepositoryTest {

    @Container
    static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:15")
            .withDatabaseName("testdb");

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

    @Test
    void customQuery_worksOnRealPostgres() { ... }
}

Reusing containers across tests — the performance fix

Starting a container per test class is slow. The fix is declaring the container static (shared within a class) and using Spring's context caching so the same context — and same container — is reused across test classes that share the same configuration.

For even better performance, use the .withReuse(true) flag — Testcontainers keeps the container alive between test runs (across JVM restarts), so the first run is slow, subsequent runs are fast.

@Container
static PostgreSQLContainer<?> postgres =
    new PostgreSQLContainer<>("postgres:15")
        .withReuse(true); // container survives JVM restart

Beyond databases

Testcontainers works for any Docker image — Kafka, Redis, LocalStack (AWS), Wiremock. I use it for Kafka consumer tests especially: spin up a real broker, publish a message, assert the consumer processed it correctly. There's no reliable way to test that with mocks.

Direct answer

Async and event-driven code is where most testing strategies break down, because the code you're trying to assert runs on a different thread, at an unknown time after the test body. If you assert immediately after triggering the async work, the work often hasn't run yet — your test passes or fails non-deterministically.

Option 1 — disable async in tests

The simplest approach: override the task executor in your test configuration to use a synchronous executor. @Async still works but runs on the calling thread, so there's no timing issue.

@TestConfiguration
class SyncAsyncConfig {
    @Bean
    @Primary
    TaskExecutor taskExecutor() {
        return new SyncTaskExecutor(); // runs on calling thread — no async
    }
}

Good for unit/service-level tests. Not ideal if the async boundary itself is what you're testing.

Option 2 — Awaitility for real async assertions

When you want to test that the async work actually happens asynchronously, use Awaitility to poll until the condition is met or a timeout is reached:

import static org.awaitility.Awaitility.await;

@Test
void publishEvent_asyncListenerProcesses_withinTimeout() {
    eventPublisher.publishEvent(new OrderPlacedEvent(orderId));

    await().atMost(2, SECONDS)
           .untilAsserted(() ->
               verify(notificationService, times(1)).sendConfirmation(orderId)
           );
}

Awaitility retries the assertion block until it passes or the timeout expires. It's far better than Thread.sleep() — no arbitrary waits, no flaky tests from timing differences.

Testing Spring application events

For @EventListener and @TransactionalEventListener, test that the event was published using a captured list or a @RecordApplicationEvents annotation (Spring Boot 2.4+):

@SpringBootTest
@RecordApplicationEvents
class OrderServiceEventTest {

    @Autowired ApplicationEvents events;
    @Autowired OrderService orderService;

    @Test
    @Transactional
    void placeOrder_publishesOrderPlacedEvent() {
        orderService.placeOrder(newOrder());

        assertThat(events.stream(OrderPlacedEvent.class))
            .hasSize(1)
            .first()
            .extracting(OrderPlacedEvent::getOrderId)
            .isEqualTo("ORD-001");
    }
}

Direct answer

TDD in its pure form — write a failing test, write minimum code to pass, refactor — works very well for business logic with clear rules: validation, calculations, state machines. It forces you to think about the interface before the implementation, and the test suite you end up with is genuinely useful because it was written to drive design, not just for coverage.

But I'm pragmatic about it. I don't TDD everything, and I think teams that insist on strict TDD for all code usually end up with slow delivery and test suites that test implementation details rather than behaviour.

Where TDD works well

• Complex business rules — pricing engines, discount calculators, eligibility checks, state machine transitions. The tests become the spec.
• Bug fixes — write a failing test that reproduces the bug first, then fix it. Guarantees the bug never regresses.
• Refactoring — if you have tests first, you can refactor aggressively and know immediately if you broke behaviour.

Where TDD slows you down

• Exploratory work — when you don't know the design yet, writing tests first is hard. I prefer to spike, find the right shape, then write tests before merging.
• Infrastructure glue — Spring config classes, Kafka consumer wiring, Flyway migrations. These are better covered by integration tests, not TDD unit tests.
• UI / controller layer — the interface changes frequently in early development. TDD here creates tests that break constantly for the wrong reasons.

How I apply it in practice

I use TDD strictly for the domain/service layer where business rules live. For everything else — controllers, repositories, config — I write tests after the implementation is stable but before the PR is merged. The rule I follow: no PR without tests, but tests don't always have to come first.

The most important TDD habit that doesn't require strict red-green-refactor: write the test before you call it "done." Don't write code, ship it, and add tests later. That path leads to code that's hard to test, and tests that are retrofitted to pass rather than to verify behaviour.

The problem: integration test sprawl in microservices

In a microservices architecture, verifying that Service A's client correctly calls Service B's API has two naive approaches — both painful:

• Full integration tests: spin up Service B (plus its DB, Kafka, etc.) in your CI. Slow, brittle, hard to maintain.
• Mocking: mock the HTTP call in Service A's tests. Fast, but the mock can diverge from Service B's actual behavior — you get passing tests and broken production.

Contract testing gives you a third option: verify the contract independently on each side, with minimal infrastructure, and break the build at the producer if a change violates any consumer's contract.

Pact — the consumer-driven flow

// CONSUMER SIDE — defines what it expects from the producer
@ExtendWith(PactConsumerTestExt.class)
class UserClientPactTest {

    @Pact(consumer = "order-service", provider = "user-service")
    public RequestResponsePact getUserPact(PactDslWithProvider builder) {
        return builder
            .given("user 42 exists")
            .uponReceiving("a request for user 42")
                .path("/users/42")
                .method("GET")
            .willRespondWith()
                .status(200)
                .body(new PactDslJsonBody()
                    .numberType("id", 42)
                    .stringType("name", "Alice")
                    .stringType("email"))  // type matching, not exact values
            .toPact();
    }

    @Test
    @PactTestFor(pactMethod = "getUserPact")
    void testGetUser(MockServer mockServer) {
        // Pact starts a real HTTP mock server from the contract definition
        UserDto user = userClient.getUser(42);
        assertThat(user.id()).isEqualTo(42);
        // Pact verifies your client correctly sends the expected request
        // AND correctly parses the response
    }
    // After running, Pact writes a .json contract file — publish to Pact Broker
}

// PRODUCER SIDE — verifies it satisfies the consumer's contract
@Provider("user-service")
@PactBroker(url = "https://pact-broker.internal")
@SpringBootTest(webEnvironment = RANDOM_PORT)
class UserServicePactVerificationTest {

    @State("user 42 exists")
    void userExists() {
        // Set up test data matching the consumer's "given" state
        userRepo.save(new User(42L, "Alice", "alice@example.com"));
    }
    // Pact fetches all contracts from the broker, replays each request,
    // and asserts the response matches what the consumer declared.
    // If user-service drops the "email" field, this test fails.
}

Spring Cloud Contract — the Spring-native alternative

Spring Cloud Contract (SCC) is producer-driven: the producer defines the contracts, and SCC generates both the producer's test stubs and WireMock JSON files that consumers use. The flow is inverted compared to Pact.

// Contract defined by the PRODUCER (Groovy DSL or YAML)
// src/test/resources/contracts/getUserById.groovy
Contract.make {
    request {
        method GET()
        url '/users/42'
    }
    response {
        status 200
        body(id: 42, name: 'Alice', email: regex('.+@.+'))
        headers { contentType applicationJson() }
    }
}

# SCC generates from this contract:
# 1. A @SpringBootTest-based producer test that hits the real endpoint
# 2. A WireMock stub JSON that consumers use in their tests:
#    { "request": { "method": "GET", "url": "/users/42" },
#      "response": { "status": 200, "body": "{\"id\":42, ...}" } }

# Consumer uses the published stub (no real server needed)
@AutoConfigureStubRunner(
    ids = "com.example:user-service:+:stubs:8090",
    stubsMode = StubRunnerProperties.StubsMode.REMOTE
)

Pact vs Spring Cloud Contract — when to use each