> Mocks work well because you can quickly define them in a given unit test and forget about it.

They do, yes. But:

* the mock syntax is complex and verbose. e.g. "repo.Setup(x => x.Method(It.IsAny<string>(), It.IsAny<List<int>>())) .ReturnsAsync(() => ...." is not the easiest syntax.

The syntax for a fake is just regular old "class FakeFoo: IFoo" with trivial method implementations and no library needed to make it work.

* the mock syntax does not scale. Your 5 lines of setup in one test does not help you in a different test class. So it gets repeated.

Soon you might find that the Fake is easier to read, easier to maintain, and fewer lines of code than all the mocks.

As the article says: "their self-contained nature makes them reusable as well, which lends itself to better long-term maintainability." Not all our code is "do it quickly and forget about it", especially where you see that same thing or minor variations of it done over and over again in related tests.

Mocks win here when you do something different, once only. Fakes win in the opposite cases.

> I can see fakes being useful in certain cases,

This is true, but it's also true that Fakes are _underused_ in general in in the .NET world. People reach for mocking frameworks as if they are the only tool.