How are fakes, as described in this article, not also implementation-aware testing?
Instead of counting how many times a method is called (mock), your test just gets to test the outcome of the overall operation (fake).
That's an expectation which is an extra optional layer on top of mocking. The important difference between mock and fake is that a separate mock has to be created for every single test, but a fake needs only be created once for all tests that use the faked dependency.
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.
So they are coupled to the implementation of the object in any case!
> 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.
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.
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.
furthermore:
https://news.ycombinator.com/item?id=24774752
which demonstrates my point. I don't want to have to write tests for tests.
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?
There is no need for Mocks or Fakes with pure functions.
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.