Because they don't just implement a part of the interface (just one store method, or just one of two load methods). They try to create a fully functional fake of the original class.
In this case instead of storing the blobs via a REST interface or a database connection, it just keeps it in memory. So it should mostly behave like the real implementation, but is not suitable for production, as it doesn't persist the data.
The only things that are missing there are real life latency or maybe exceptions because of connectivity issues.
> Because they don't just implement a part of the interface (just one store method, or just one of two load methods). They try to create a fully functional fake of the original class.
So shouldn't fakes have their own tests as well? Mocks don't need tests (at least in C# with a framework) because no new class is ever written.
Anyway most of these issues are inherently linked to the nature of OOP and are a direct trade off to its benefits.
Both Mocks and Fakes have advantages and drawbacks, but the OP doesn't reflect that.
I wish articles written on that subject would take a step back and explore how code can be written so that the burden of testing is reduced to a minimum.
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?
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.
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.
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.
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.
> 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.
In this case instead of storing the blobs via a REST interface or a database connection, it just keeps it in memory. So it should mostly behave like the real implementation, but is not suitable for production, as it doesn't persist the data.
The only things that are missing there are real life latency or maybe exceptions because of connectivity issues.