ApplicationContextRunner

## The scenario Auto-configuration commonly gates a bean like this: ```java @AutoConfiguration public class MyAutoConfiguration { @Bean @ConditionalOnProperty(prefix = "my.feature", name = "enabled", havingValue = "true") MyService myService() { return new MyService(); } } ``` You want tests proving: (1) property `true` → bean present, (2) property `false`/absent → bean absent. ## withPropertyValues `withPropertyValues(String... pairs)` adds `key=value` entries into the context's `Environment` as a property source, identical in effect to putting them in `application.properties`. It accepts multiple pairs and can be called repeatedly (values accumulate). This is how `@ConditionalOnProperty` sees them, because that condition resolves against the `Environment`. ## The two-case test ```java private final ApplicationContextRunner runner = new ApplicationContextRunner() .withConfiguration(AutoConfigurations.of(MyAutoConfiguration.class)); @Test void beanPresentWhenEnabled() { runner.withPropertyValues("my.feature.enabled=true") .run(ctx -> assertThat(ctx).hasSingleBean(MyService.class)); } @Test void beanAbsentWhenDisabled() { runner.withPropertyValues("my.feature.enabled=false") .run(ctx -> assertThat(ctx).doesNotHaveBean(MyService.class)); } @Test void beanAbsentWhenMissing() { runner.run(ctx -> assertThat(ctx).doesNotHaveBean(MyService.class)); } ``` ## Key assertions - `hasSingleBean(Type.class)` — exactly one bean of that type. Preferred over `hasBean(name)` because it's type-based and catches accidental duplicates. - `doesNotHaveBean(Type.class)` — no bean of that type; this is what proves a condition *backed off*. - `getBean(Type.class)` — chain further AssertJ on the actual instance, e.g. `assertThat(ctx).getBean(MyService.class).extracting("timeout").isEqualTo(30)`. ## matchIfMissing gotcha If the condition uses `matchIfMissing = true`, the bean should exist even with **no** property. Test that by running with no `withPropertyValues` and asserting `hasSingleBean`. Conversely a common bug is forgetting `matchIfMissing` and being surprised the bean is absent by default — the runner makes that explicit. ## Immutability matters here Each `withPropertyValues(...)` returns a *new* runner. If you wrote `runner.withPropertyValues(...);` on its own line and then called `runner.run(...)`, the property would be lost — you must use the returned instance (chain it, as above). This is the single most common mistake. ## Property value types Everything you pass is a string, parsed by Spring's normal relaxed binding / `@ConditionalOnProperty` `havingValue` string comparison. `havingValue="true"` matches the string `true`; there's no type coercion surprise because the condition compares strings.