Testing — the most volatile section you own

@TestConfiguration adds. A plain nested @Configuration replaces.

@TestConfiguration is meta-annotated with @TestComponent, which excludes it from the bootstrapper's search for a primary configuration — so the app's real config is still found, and the test class's beans are merged on top. A plain nested @Configuration is a valid primary candidate, so the search stops there and your application configuration never loads.

@SpringBootTest
class MyTest {
    @TestConfiguration          // additive — app config still loads
    static class Extra {
        @Bean Clock testClock() { return Clock.fixed(Instant.EPOCH, ZoneOffset.UTC); }
    }
}

Nothing — Boot walks up the package tree and finds @SpringBootConfiguration itself

If the @SpringBootApplication class sits in the root package and the tests mirror that package structure, discovery is automatic. SpringBootTestContextBootstrapper runs SpringBootConfigurationFinder, which searches upward from the test's package for the first @SpringBootConfiguration, and uses its @ComponentScan and @EnableAutoConfiguration exactly as in production.

Contexts are cached, not rebuilt per test class

The four TestContext facts this question rotates through:

• Caching — same configuration ⇒ same context, reused. A new context is built only when the config differs (which is why @MockBean, @TestPropertySource and @ActiveProfiles all fragment the cache).
• Injection — use @Autowired in the test class. You never need context.getBean().
• Inheritance — @ContextConfiguration and @ActiveProfiles are inherited from a superclass, which is how abstract base test classes work.
• Optional configuration — @ContextConfiguration need not name a file; conventions and nested @Configuration classes are enough.

MockMvc, @ControllerAdvice, WebMvcConfigurer — not TestRestTemplate

TestRestTemplate makes real HTTP calls, so it needs a real server. Only @SpringBootTest(webEnvironment = RANDOM_PORT) (or DEFINED_PORT) starts one. @WebMvcTest never starts a server — it dispatches through MockMvc instead.

The false statement was "Spring Boot does not support @WebMvcTest"

All four options were about things Spring genuinely does: Mockito integrates via @Mock and @MockBean; the TestContext Framework is real; it supports JUnit 4 (@RunWith(SpringRunner.class)), JUnit 5 (@ExtendWith(SpringExtension.class)) and TestNG. The single planted falsehood was a denial of @WebMvcTest.

All three listed statements were true, so the answer was "None of the above"

The three true statements were: it auto-configures Spring MVC infrastructure; it is meta-annotated with @ExtendWith(SpringExtension.class); it auto-configures MockMvc. With nothing false among them, the catch-all becomes the answer.

The mock servlet classes — MockHttpServletRequest and friends

spring-test ships mock implementations of the Servlet API in org.springframework.mock.web, so you can exercise controllers and filters with no container at all:

Five of the six statements were true — only "@SpringBootTest disables Flyway" was false

Flyway is auto-configured whenever it is on the classpath, and its migrations run as the ApplicationContext starts — before any test method executes.

Every option was right — JUnit, Spring Test + Boot Test, AssertJ, Hamcrest

The full contents of the starter, which is worth knowing as a list because the exam samples from it:

• JUnit Jupiter — the JUnit 5 engine (plus the Vintage engine in older Boot versions)
• Spring Test — MockMvc, the TestContext Framework, transactional test support
• Spring Boot Test and spring-boot-test-autoconfigure — @SpringBootTest, the slices
• AssertJ — fluent assertions (assertThat(x).isEqualTo(y))
• Hamcrest — matcher-style assertions
• Mockito — mocking
• JSONassert and JsonPath — JSON assertions
• XMLUnit — XML assertions

Three statements were true; the two false ones you correctly rejected

With @ActiveProfiles({"test", "integration"}):

In a test, @TestPropertySource — above environment variables and command-line arguments

See master table 3 for the full ladder. The distinction the exam is testing: command-line arguments win at runtime; @TestPropertySource wins in a test.

@SpringBootTest
@TestPropertySource(properties = "my.custom.value=test123")
class MyTest {
    @Value("${my.custom.value}") String value;   // "test123" — beats everything else
}

MockitoExtension (JUnit 5) or MockitoJUnitRunner (JUnit 4) — or call openMocks(this)

See master table 4 for the full @Mock/@MockBean split. The three ways to activate @Mock:

@ExtendWith(MockitoExtension.class)          // JUnit 5 — preferred
@RunWith(MockitoJUnitRunner.class)           // JUnit 4
MockitoAnnotations.openMocks(this);          // manual, in @BeforeEach

The manual route works but loses strict stubbing — the runner and the extension both fail the test on unused stubs, which the manual call does not.