What's the difference between registering a class via withConfiguration(AutoConfigurations.of(...)) versus withUserConfiguration(...) in a runner, and why does it matter for @ConditionalOnMissingBean?

## Two ways to register classes The runner offers distinct registration paths with different *semantics*: - `withConfiguration(AutoConfigurations.of(A.class, B.class))` — registers A and B as **auto-configuration** classes. `AutoConfigurations` is a special `Configurations` subtype that Spring Boot orders and processes exactly like production auto-config: sorted by `@AutoConfigureOrder`, `@AutoConfigureBefore`, `@AutoConfigureAfter`, and applied **after** all user configuration. - `withUserConfiguration(A.class)` / `withBean(...)` — registers A as ordinary **user** configuration, processed **before** auto-configuration, with no auto-config ordering semantics. ## Why ordering is not cosmetic — @ConditionalOnMissingBean `@ConditionalOnMissingBean` evaluates against the beans *already defined at the moment the condition runs*. Bean definitions are processed in a deterministic order; auto-config runs last so a user-defined bean of the same type already exists and the auto-config's `@ConditionalOnMissingBean` backs off. This is the mechanism that lets your `application.properties`-style defaults be overridden by a user's explicit `@Bean`. If you register your auto-configuration through `withUserConfiguration`, it's no longer 'last'. It competes as a peer user bean with undefined relative ordering, so `@ConditionalOnMissingBean` may evaluate *before* the user's bean is registered — producing a duplicate bean, or the wrong winner. The test would then either pass when production fails, or fail when production is fine. Both are dangerous: your test no longer models reality. ## Canonical override test ```java private final ApplicationContextRunner runner = new ApplicationContextRunner() .withConfiguration(AutoConfigurations.of(MyAutoConfiguration.class)); @Test void userBeanWinsOverAutoConfigDefault() { runner.withUserConfiguration(UserConfig.class) // user bean: processed first .run(ctx -> { assertThat(ctx).hasSingleBean(MyService.class); // exactly one assertThat(ctx).getBean(MyService.class) .isSameAs(ctx.getBean(UserConfig.class).myService()); }); } static class UserConfig { @Bean MyService myService() { return new MyService("custom"); } } ``` Here `MyAutoConfiguration#myService` is annotated `@ConditionalOnMissingBean(MyService.class)`. Because the auto-config is registered via `AutoConfigurations.of`, it runs after `UserConfig`, sees the user's bean, and backs off — leaving exactly one bean (the user's). Swap to `withUserConfiguration(MyAutoConfiguration.class)` and this guarantee evaporates. ## @AutoConfigureAfter / ordering between auto-configs The same distinction governs inter-auto-config ordering. If `BAutoConfiguration` declares `@AutoConfigureAfter(AAutoConfiguration.class)` and you want to test that B sees A's beans, both must be registered inside one `AutoConfigurations.of(A.class, B.class)` so the ordering annotations are honored. Registered as user config, the ordering hints are ignored. ## Practical rule - Class-under-test that IS an auto-configuration → `withConfiguration(AutoConfigurations.of(...))`. - Simulated user/application beans → `withUserConfiguration(...)` or `withBean(...)`. Mixing them this way makes the runner faithfully reproduce Spring Boot's real processing order, which is the whole point of using it to test conditions. ## Subtlety: withBean and order `withBean(...)` also registers as user-level and is seen before auto-config — perfect for injecting a stand-in dependency the auto-config expects, or for simulating a user-provided bean that should trigger back-off, without writing a `@Configuration` class.