4 ms·

How are fakes, as described in this article, not also implementation-aware testing?

andix 6y ago
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.
- hackerfromthefu 6y ago
  >> .. fully functional fake of the original class. So they are coupled to the implementation of the object in any case!
  - silveroriole 6y ago
    I’d say rather that they’re coupled to the behaviour of the object.
    - bluGill 6y ago
      Not exactly - they are coupled to the interface contract. The behavior can be very different.
      - srtjstjsj 6y ago
        Contracted behavior is same.
  - tyrrrz 6y ago
    Quoting the article: > 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.
    - doubletgl 6y ago
      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.
- throw_m239339 6y ago
  > 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.
  - andix 6y ago
    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.
    - throw_m239339 6y ago
      > 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 https://news.ycombinator.com/item?id=24774752 which demonstrates my point. I don't want to have to write tests for tests.
      - srtjstjsj 6y ago
        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.
ragnese 6y ago
The fake is coupled to the "real" implementation of the interface. But the test that uses the fake is no longer coupled to the implementation of the fake/mock. Instead of counting how many times a method is called (mock), your test just gets to test the outcome of the overall operation (fake).
- srtjstjsj 6y ago
  > counting how many times 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.

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.

hackerfromthefu 6y ago
>> .. fully functional fake of the original class. So they are coupled to the implementation of the object in any case!
- silveroriole 6y ago
  I’d say rather that they’re coupled to the behaviour of the object.
  - bluGill 6y ago
    Not exactly - they are coupled to the interface contract. The behavior can be very different.
    - srtjstjsj 6y ago
      Contracted behavior is same.
- tyrrrz 6y ago
  Quoting the article: > 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.
  - doubletgl 6y ago
    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.
throw_m239339 6y ago
> 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.
- andix 6y ago
  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.
  - throw_m239339 6y ago
    > 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 https://news.ycombinator.com/item?id=24774752 which demonstrates my point. I don't want to have to write tests for tests.
    - srtjstjsj 6y ago
      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.

ragnese 6y ago

The fake is coupled to the "real" implementation of the interface. But the test that uses the fake is no longer coupled to the implementation of the fake/mock. Instead of counting how many times a method is called (mock), your test just gets to test the outcome of the overall operation (fake).

srtjstjsj 6y ago
> counting how many times 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.