7 ms·

I wholeheartedly disagree with the author here. Not mocking 3rd party dependencies is a bad practice, it's how you wind up with fragile and flaky tests that can

I wholeheartedly disagree with the author here. Not mocking 3rd party dependencies is a bad practice, it's how you wind up with fragile and flaky tests that can't always be ran locally. Not mocking 3rd party is done in integration or orchestration testing. Not your unit tests.

ollien 4y ago
It depends on your language and testing framework. In C++-land, for instance, you can't mock a third party library if they don't define virtual methods, forcing you to make a wrapper (an experience with this is what taught me this mantra)
- int_19h 4y ago
  If you are mocking the library in its entirety, you just define the same classes/functions that they do - virtual or not - and then link to your implementation instead of theirs for the test build.
  - ollien 4y ago
    Heh, that's an interesting strategy. My company primarily works with gmock, and I'm not certain you could do what you describe with gmock, but yeah that would work otherwise.
- chc 4y ago
  This seems like an is-ought fallacy. What you're describing is not a "you shouldn't," it's a "you can't due to limitations in the language."
  - ollien 4y ago
    TIL about that fallacy. That's a fair point. I guess it comes in a bit differently in C++ land, because the "you shouldn't" comes into what you decide to allow to be injectable (e.g. if your constructor only accepts the third party object type, you're not gonna be able to mock it). As such, you gotta keep the principle in mind when designing your objects. That said, you're definitely right, it smells like that fallacy
    - nijave 4y ago
      I think that applies to other languages, too. There doesn't tend to be much (any?) magic mocking in Go but more "real" local HTTP servers to stub responses and duck typed fake implementations On the other hand, in Ruby and Python it's pretty trivial to monkey patch and magic mock
      - ollien 4y ago
        Go is a good example, too. Unlike C++ though, the distinction between something with dynamic dispatch (an interface) is a bit more explicit than in C++ (a class with virtual methods, which may not all be virtual). That said, in your example, yeah: if you just pass a stock http.Client around, you lose any ability to mock that short of spinning up a dummy webserver.
useful 4y ago
And his verified fakes is just a way to introduce bugs because taken to the extreme you'd have to 100% recreate the 3rd party dependency you are interacting with.
ambivalence 4y ago
There are three related terms: mocking, faking, and stubbing. They mean subtly different things, which the article points out. The author prefers the last one, and uses the middle one for complex cases, avoiding mocks altogether. But that doesn't mean he leaves third-party networking libraries run wild in unit tests. In fact, the very example he builds in the article shows how to avoid that without having to create a mock. Maybe you need to read it again?
postalrat 4y ago
"Not your unit tests." then don't write these unit tests. Use integration or orchestration testing.
christkv 4y ago
I think the sane half-way point is to hide external integrations behind a facade that you can mock for unit tests and then you verify those assumptions with proper integration tests.
- geraldwhen 4y ago
  I don’t want to find bugs in a deployed environment. The more real code paths my tests hit, the less likely that is to happen. I’ve found numerous bugs in infernal apis by being one of the only teams to prefer or even use integration tests.
- nijave 4y ago
  Yeah and the real implementation you can still do a full integration test with the real backend (send a request to a web API) if you want but limit runs to only times the facade changes
- hynek 4y ago
  Which is…precisely what the article is saying!?
hynek 4y ago
So you haven’t made it past the second heading and already felt compelled to “disagree wholeheartedly”? The article is _precisely_ about the knee-jerk reaction you’re exhibiting and trying to explain why that decades old principles makes more sense than it seems. Please search for “If you’re anything like me, that makes no sense! What else am I supposed to mock?” and read with an open mind.
- deleted 4y ago
  [deleted]
- swatcoder 4y ago
  Assuming you care about clarity and not just style, there might be some feedback to take in when people don't get the gist of what you're saying until after the second heading. Even if you want to make the writing a journey that arrives at a conclusion rather than a thesis-first argument, the presentation immediately being scattered across a bunch of embedded block quotes and long asides (your disclaimer) invites readers to lose the path, give up, and just make assumptions about the remainder. And what always happens on the internet when people do that? Comments that miss the point and confuse everybody else about what you were saying. You're right that the other commenter could have been more responsible, but odds are that someone was going to post a comment like even if it didn't happen to be them.
  - hynek 4y ago
    I put the disclaimer there, because I was afraid people would stop reading and start arguing about mocks vs fakes vs etc. But you’re right, people skip the lede (mentions counter-intuitive, I hoped that set the mood) and lose patience, so I’ll try to swap the blocks and see if the comments improve.

ollien 4y ago

It depends on your language and testing framework. In C++-land, for instance, you can't mock a third party library if they don't define virtual methods, forcing you to make a wrapper (an experience with this is what taught me this mantra)

int_19h 4y ago
If you are mocking the library in its entirety, you just define the same classes/functions that they do - virtual or not - and then link to your implementation instead of theirs for the test build.
- ollien 4y ago
  Heh, that's an interesting strategy. My company primarily works with gmock, and I'm not certain you could do what you describe with gmock, but yeah that would work otherwise.
chc 4y ago
This seems like an is-ought fallacy. What you're describing is not a "you shouldn't," it's a "you can't due to limitations in the language."
- ollien 4y ago
  TIL about that fallacy. That's a fair point. I guess it comes in a bit differently in C++ land, because the "you shouldn't" comes into what you decide to allow to be injectable (e.g. if your constructor only accepts the third party object type, you're not gonna be able to mock it). As such, you gotta keep the principle in mind when designing your objects. That said, you're definitely right, it smells like that fallacy
  - nijave 4y ago
    I think that applies to other languages, too. There doesn't tend to be much (any?) magic mocking in Go but more "real" local HTTP servers to stub responses and duck typed fake implementations On the other hand, in Ruby and Python it's pretty trivial to monkey patch and magic mock
    - ollien 4y ago
      Go is a good example, too. Unlike C++ though, the distinction between something with dynamic dispatch (an interface) is a bit more explicit than in C++ (a class with virtual methods, which may not all be virtual). That said, in your example, yeah: if you just pass a stock http.Client around, you lose any ability to mock that short of spinning up a dummy webserver.

useful 4y ago

And his verified fakes is just a way to introduce bugs because taken to the extreme you'd have to 100% recreate the 3rd party dependency you are interacting with.

ambivalence 4y ago

There are three related terms: mocking, faking, and stubbing. They mean subtly different things, which the article points out. The author prefers the last one, and uses the middle one for complex cases, avoiding mocks altogether. But that doesn't mean he leaves third-party networking libraries run wild in unit tests. In fact, the very example he builds in the article shows how to avoid that without having to create a mock. Maybe you need to read it again?

postalrat 4y ago

"Not your unit tests." then don't write these unit tests. Use integration or orchestration testing.

christkv 4y ago

I think the sane half-way point is to hide external integrations behind a facade that you can mock for unit tests and then you verify those assumptions with proper integration tests.

geraldwhen 4y ago
I don’t want to find bugs in a deployed environment. The more real code paths my tests hit, the less likely that is to happen. I’ve found numerous bugs in infernal apis by being one of the only teams to prefer or even use integration tests.
nijave 4y ago
Yeah and the real implementation you can still do a full integration test with the real backend (send a request to a web API) if you want but limit runs to only times the facade changes
hynek 4y ago
Which is…precisely what the article is saying!?

hynek 4y ago

So you haven’t made it past the second heading and already felt compelled to “disagree wholeheartedly”? The article is _precisely_ about the knee-jerk reaction you’re exhibiting and trying to explain why that decades old principles makes more sense than it seems. Please search for “If you’re anything like me, that makes no sense! What else am I supposed to mock?” and read with an open mind.

deleted 4y ago
[deleted]
swatcoder 4y ago
Assuming you care about clarity and not just style, there might be some feedback to take in when people don't get the gist of what you're saying until after the second heading. Even if you want to make the writing a journey that arrives at a conclusion rather than a thesis-first argument, the presentation immediately being scattered across a bunch of embedded block quotes and long asides (your disclaimer) invites readers to lose the path, give up, and just make assumptions about the remainder. And what always happens on the internet when people do that? Comments that miss the point and confuse everybody else about what you were saying. You're right that the other commenter could have been more responsible, but odds are that someone was going to post a comment like even if it didn't happen to be them.
- hynek 4y ago
  I put the disclaimer there, because I was afraid people would stop reading and start arguing about mocks vs fakes vs etc. But you’re right, people skip the lede (mentions counter-intuitive, I hoped that set the mood) and lose patience, so I’ll try to swap the blocks and see if the comments improve.