The source material you're reading is plain wrong. Unit tests mock external dependencies. Who designed this dependency is irrelevant. If it's external to the unit under test, it shouldn't be included as a real component in those unit tests.

The most optimistic interpretation of this guide might be that they got confused between unit and integration tests. But that is such a straightforward easy-to-spot mistake to make, which is really egregious in a guide that otherwise attempts to rigorously defined everything to then give you specific rules about every specific thing.

I've never seen the value in distinguishing between the different kinds of fake dependency, but this article goes to great lengths to define it all. I disagree with that take.

For this article to take such a declarative stance with such granularity, and then plainly fail on the advice on what should be faked in a unit test, makes it a really bad article. Them doubling down on the "because you designed it" argument compound just how misguided this article is.

I'm not saying everything in this article is wrong, but I wouldn't trust any of it based on this article alone.

The source material you're reading is plain wrong. Unit tests mock external dependencies. Who designed this dependency is irrelevant. If it's external to the unit under test, it shouldn't be included as a real component in those unit tests.

The most optimistic interpretation of this guide might be that they got confused between unit and integration tests. But that is such a straightforward easy-to-spot mistake to make, which is really egregious in a guide that otherwise attempts to rigorously defined everything to then give you specific rules about every specific thing.

I've never seen the value in distinguishing between the different kinds of fake dependency, but this article goes to great lengths to define it all. I disagree with that take, not so much the exercise of naming things in and of itself (to each their own), but the undertone that there are very different treatments based for all these fake dependency variants.

In my opinion, it's an act of creating an arbitrary distinction only to then be able to sell your guide that helps you navigate said arbitrarily complex maze of rules. The article's content feels bloated with the intention of appearing to convey more information than is actually relevant in practice.
The article ending itself on a cliffhanger that suggests you should read (and therefore buy) their book seems to further support this interpretation of the article's content.

For this article to take such a declarative stance with such granularity, and then plainly fail on the advice on what should be faked in a unit test, makes it a really bad article. Them doubling down on the "because you control/manage it" argument further compounds how misguided this article is.

I'm not saying everything in this article is wrong, but I wouldn't trust any of it based on this article alone.