Earlier quoted context omitted.
Here let me fix that for you: "document why it is so in an executable test".
Sometimes possible, but not always. An executable test is good for documenting what a piece of code should do, but not always entirely sufficient for documenting why .
Sure, a unit test might just document what code is doing, because that's really the only why. But most testing effort should go into describing the why more carefully, which must be done at a higher level, as close as possible to how a user will interact with the thing.
Writing tests at the user's level and not getting bogged down in minutia requires careful factoring of the what and why. The what changes frequently, so if most of your tests are overly focused on the what, you will constantly need to update them as the code changes. The why changes much more slowly, so if your tests are written to exercise the why rather than the how, they will be resilient to changes in the implementation.
Of course, the what has to be somewhere, and when it changes there will need to be corresponding test updates, but these shouldn't require updating each individual test. The what can be kept cleanly factored out into helpers, leaving the why to remain as the essence of each test.