Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prefer Fakes over Mocks

tyrrrz.me

Post reply on HN
Print view View original

111–120 of 125 posts

Re: Prefer Fakes over Mocks

#111

Post by srtjstjsj »

throw_m239339 wrote: post #61
andix wrote: post #43

Earlier quoted context omitted.

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…

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.

Re: Prefer Fakes over Mocks

#113

Post by srtjstjsj »

SassyGrapefruit wrote: post #81

I watch more people overcomplicate their lives when it comes to unit testing. The problem discussed in this article is not one of mock vs. fake its actually about how this individual chose to engineer their application. First I'll introduce some axioms... 1. Mixing unit and integration testing is not ideal. If you are doing unit testing focus on verifying the code paths within the unit. When considering the collabora…

"Making code more testable" by moving the logic into functions you don't test, is not a winning strategy.

Re: Prefer Fakes over Mocks

#114

Post by srtjstjsj »

Ronsenshi wrote: post #2

Not particularly convincing. Mocks work well because you can quickly define them in a given unit test and forget about it. I can see fakes being useful in certain cases, but only just in certain cases. Could be my inexperience with C#, but it didn't do justice describing the point in code samples.

With a fake you don't need to rewrite its behavior in every single unit test that friends on it. One fake for each datastore, shared by all tests.

Re: Prefer Fakes over Mocks

#115

Post by hinkley »

srtjstjsj wrote: post #106
hinkley wrote: post #71

Earlier quoted context omitted.

Mocks for your own code, fakes for external dependencies but in both cases only where you can’t rework your most of your code to consume the outputs of dependencies instead of soliciting them. Fixtures trump mocks and fakes. Having multiple tests fail for the same reason is a waste of effort, either now or in the future (when new features are added or the constraints otherwise change). Sometimes you have to depend on…

Why would you mock your own code, when you have your own real code right there?

Because that’s an integration test and I’m writing unit tests, which scale much higher.

Re: Prefer Fakes over Mocks

#116

Post by mypalmike »

srtjstjsj wrote: post #106
hinkley wrote: post #71

Earlier quoted context omitted.

Mocks for your own code, fakes for external dependencies but in both cases only where you can’t rework your most of your code to consume the outputs of dependencies instead of soliciting them. Fixtures trump mocks and fakes. Having multiple tests fail for the same reason is a waste of effort, either now or in the future (when new features are added or the constraints otherwise change). Sometimes you have to depend on…

Why would you mock your own code, when you have your own real code right there?

As parent explained, if you use real objects, you end up testing the dependencies of those objects, and transitively the dependencies thereof, etc. For unit tests, the goal is to test the unit, not its dependencies. In practice, using real objects has many downsides including complex setup functions and a need to make changes to many layers of complex tests in order to implement even small code changes.

Re: Prefer Fakes over Mocks

#117

Post by doubletgl »

tyrrrz wrote: post #52
hackerfromthefu wrote: post #22

Earlier quoted context omitted.

>> .. fully functional fake of the original class. So they are coupled to the implementation of the object in any case!

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 betwee…

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.

Re: Prefer Fakes over Mocks

#118

Post by etripe »

chriswarbo wrote: post #86
etripe wrote: post #50

Earlier quoted context omitted.

The benefits you describe for OOP can be achieved in FP through function composition. DI doesn't have to mean you set up a container, you know. > I know that something akin to this is theoretically possible in functional languages, but I've found that in practice it's more difficult. Could you explain what you think is hard about it?

Function composition doesn't spring to mind when I think fakes/mocks/testing. As a long-time functional programmer, the things I'd reach for are: Higher-order functions: rather than taking a 'service object' as an argument, and calling one or two of its methods, we can accept the methods/functions we need as arguments. Tests can pass in their own functions, which looks a lot like mocking but doesn't need any tricks o…

I'm relatively new to FP, so maybe I'm getting my terminology wires crossed. Perhaps instead of function composition I should have said currying and you would have gotten my drift. That is what you seem to be saying in your second paragraph.

Re: Prefer Fakes over Mocks

#119

Post by rocqua »

jrockway wrote: post #102
rocqua wrote: post #37

Earlier quoted context omitted.

> if you can modify the system to make testing against it easier, that's even better. What do you mean here? Changing your testing system, or changing the real system?

Changing the real system to add the hooks you need. Complexity often exists around waiting for events to happen (the real system doesn't need notifications, but you don't want your tests to run forever when they're failing), clocks (time.Now() is difficult to test), things like that.

Personally I am loath to add extra functionality to the real system just to make testing easier. I am massively in favor of keeping the complexity in the real system down. Adding more hooks, or increasing the interface of the real system, just to make it more testable feels wrong.

This is why I'd want test to just have a lot more 'leeway' than normal code. Essentially I want heavy hooking, introspection and reflexivity but only for tests.

Re: Prefer Fakes over Mocks

#120

Post by throw_m239339 »

marcosdumay wrote: post #103
throw_m239339 wrote: post #32

Earlier quoted context omitted.

> 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 trad…

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…

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

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

Post reply on HN