> It may also appear that the details we have to take into account here are not that different from the implementation-aware assumptions we were making when using mocks, as neither are actually governed by the interface of the component. However, the major distinction is that the coupling we institute here is between the test double and the real implementation of the component, rather than between the test double and the internal specifics of its consumer.
Ok, so the implementation-awareness lies in the fake itself, not the code setting up mocks. But creating the fake is part of testing, if you follow this approach. So you're still doing implementation-aware testing in the end. Don't get me wrong, fakes are a cool idea. But the article is overselling their advantages a bit I think.
> It may also appear that the details we have to take into account here are not that different from the implementation-aware assumptions we were making when using mocks, as neither are actually governed by the interface of the component. However, the major distinction is that the coupling we institute here is between the test double and the real implementation of the component, rather than between the test double and the internal specifics of its consumer.