Serguey Asael Shinder: A default the code does not read is documentation that lies
This week's Micronaut bug is small, and the shape of it is common. A configuration record declared a default of two seconds with @Bindable(defaultValue = "2s"). The generated configuration schema read that annotation and told everyone the default was two seconds. The code that actually built the bean checked @Nullable first and handed over null. Two readers of the same annotation, two different answers, and the one users could see was the wrong one. The fix put the checks in the right order. The lesson is about why it took a release to notice.
The description is easier to look at than the behaviour. A schema, a README, a Javadoc comment or an OpenAPI file is something people read. The resolution code is something people trust. When the two disagree, the readable one wins every review, because nobody opens a debugger to confirm a number they have just seen written down.
Two copies of a fact drift. The default was stated once, in the annotation, but it was interpreted twice, by the schema generator and by the binder. Each interpretation is a copy. Copies that are not compared against each other will eventually disagree, and nothing fails when they do: the schema is valid, the bean starts, the value is simply different from what the page says.
Test the thing that runs. The useful test is not "the schema contains 2s". It is "start the context with nothing configured and read the value from the bean". That is exactly the test the pull request added, and it fails on the old code. A test that checks the documentation against itself can only ever pass.
And test both directions. A default needs two checks: unconfigured, you get the default; configured, your value wins. The Micronaut tests do both. One without the other proves less than it looks.
When the same fact appears in two places, the place that executes is the source of truth, and the other is a claim about it. Write the test against the source of truth, and let it check the claim.