Introduction

When a Spring Boot integration test starts the application context and a bean is unexpectedly present or missing, the auto-configuration report is often more useful than the final exception message. The goal is to make Spring Boot print its condition evaluation details during test startup so you can see which auto-configurations matched, backed off, or were skipped.

Enable Debug Mode for the Fastest Signal

The quickest way to expose the auto-configuration report is to set debug=true for the test context.

1import org.junit.jupiter.api.Test;
2import org.springframework.boot.test.context.SpringBootTest;
3
4@SpringBootTest(properties = "debug=true")
5class ApplicationIT {
6
7    @Test
8    void contextLoads() {
9    }
10}

With debug mode enabled, Spring Boot prints the condition evaluation report during startup. This is often enough to explain why a bean from an auto-configuration class was or was not applied.

Use Targeted Logger Categories

Sometimes full debug mode is too noisy for a large test suite. In that case, raise logging only for the relevant packages in test configuration.

1logging:
2  level:
3    org.springframework.boot.autoconfigure: DEBUG
4    org.springframework.boot.autoconfigure.condition: DEBUG

Place that in src/test/resources/application-test.yml and activate the test profile.

1import org.springframework.test.context.ActiveProfiles;
2
3@SpringBootTest
4@ActiveProfiles("test")
5class ApplicationIT {
6}

This produces more focused diagnostic output than turning on broad debug logging for the entire framework.

Trigger It from the Build When Needed

If you want the extra output only for one run, pass the debug property at execution time instead of baking it into the test class.

./gradlew test -Ddebug=true

That is convenient when a failing test appears only in CI or only on one developer machine and you want a temporary high-signal rerun.

Capture Output in the Test

Sometimes you want to assert that startup emitted a particular diagnostic message. Spring Boot provides OutputCaptureExtension for that use case.

1import org.junit.jupiter.api.Test;
2import org.junit.jupiter.api.extension.ExtendWith;
3import org.springframework.boot.test.system.CapturedOutput;
4import org.springframework.boot.test.system.OutputCaptureExtension;
5
6@ExtendWith(OutputCaptureExtension.class)
7class AutoConfigLogIT {
8
9    @Test
10    void logsConditionReport(CapturedOutput output) {
11        // start the context in the real test setup
12        assert output.getOut().contains("CONDITIONS EVALUATION REPORT");
13    }
14}

This is useful when you are preserving a regression test around a known auto-configuration path.

Use ApplicationContextRunner for Narrow Auto-Config Problems

Full integration tests are not always the best tool if the real question is just whether one configuration class matches under specific properties. In that case, ApplicationContextRunner gives faster and more targeted feedback.

1import org.junit.jupiter.api.Test;
2import org.springframework.boot.autoconfigure.AutoConfigurations;
3import org.springframework.boot.test.context.runner.ApplicationContextRunner;
4
5class MyAutoConfigurationTest {
6
7    private final ApplicationContextRunner runner =
8        new ApplicationContextRunner()
9            .withConfiguration(AutoConfigurations.of(MyAutoConfiguration.class))
10            .withPropertyValues("feature.enabled=true");
11
12    @Test
13    void createsBeanWhenEnabled() {
14        runner.run(context -> {
15            assert context.containsBean("myBean");
16        });
17    }
18}

This is not a replacement for integration logging, but it is often the quickest way to isolate conditional behavior.

Read the Report with the Right Questions

The condition report becomes much easier to use if you read it as a set of answers to a few practical questions:

• which auto-configurations matched completely
• which conditions failed and why
• which beans caused back-off because user configuration already supplied one
• which missing classes or properties prevented activation

That framing turns the report from a wall of text into a map of why the context looks the way it does.

Common Pitfalls

One pitfall is expecting the report without enabling either debug=true or the relevant logging categories. Spring Boot does not print this level of detail by default.

Another is enabling DEBUG for everything and then losing the useful lines in a flood of unrelated output. Narrow categories are usually better.

Teams also spend too much time reading the final bean-creation exception while ignoring the condition report that explains the earlier decision chain.

Summary

• Set debug=true to get the fastest auto-configuration report during test startup.
• Use targeted logger categories when full debug mode is too noisy.
• Pass debug settings from the build command when you need a temporary diagnostic run.
• Capture startup output in tests when you need assertions around logging behavior.
• Use ApplicationContextRunner when the problem is narrow auto-configuration logic rather than full integration wiring.