Also, in the 90s we talked about tests as another indication of programmer intent. Since we couldn't get developers to document their code and "design as a practice" fell out of favor, tests were the only thing left indicating how the code was intended to be used.

The linked article is a bit wordy, but I think what he's trying to say is: write tests exercising the behavior of interfaces because you may want to change your implementation some day. The drawback of this approach is we don't have a universal way to express Bertrand-Russell-esque contracts on interfaces, so testing behavior when you provide "unsupported" inputs is rather ad hoc.