On the best scenario, your fakes just replace some standard components your have on production with other standard components, and keep everything else equal. On those cases, no they don't need tests. But when you are doing something weirder, they pretty much do.

On the best scenario, your mocks are just data that doesn't have timing characteristics, don't react to the system being tested, and are short enough to not need any kind of compression (in loops or gzip). On those cases, they don't need tests. But if you are doing anything weirder, they pretty much do.

I honestly don't see any sense in separating them in categories like if they had discreete non-overlapping mono-dimensional properties.

Anyway, why do you claim any of that is specific to OOP?

> Anyway, why do you claim any of that is specific to OOP?

There is no need for Mocks or Fakes with pure functions.

And in what paradigm do your programs consist of only pure functions? Certainly not on FP, where IO is explicitly added to a lot of code.

Anyway, there isn't much difference between mocking a unity and passing some static data into your functions and comparing the results with the expected ones.

Why do fakes need tests, but mocks don't?

In one case you create the class on your own, in the other case the mocking framework does that for you on the fly. With both approaches you can do very basic or very complicated things.

Or do you have a rule in your company that every class needs a test? Maybe this rule is the problem.

> Why do fakes need tests, but mocks don't?

because no new class or method is created with mocks, it's merely declarative, no new logic is created than needs to be tested. Fakes very much have logic since they are implementations of classes.

> Or do you have a rule in your company that every class needs a test? Maybe this rule is the problem.

No Fakes are, not the fact that every unit should be tested. Fakes are very much a unit, the fact that they are classes is irrelevant.

furthermore:

https://news.ycombinator.com/item?id=24774752

which demonstrates my point. I don't want to have to write tests for tests.

To put it differently, mocks aren't tested because they can't be wrong, be at they are "not even wrong". You have to have faith that mock behavior is actually a reasonable emulation of the real system, without ever checking. The weakness is that your tests of the system under test don't help you find flaws in how the system under test uses the lower level dependency, because you are simply forcing the lower level dependency to behave the way you wish it would.