Hacker News Reader

Comment by malfist | Hacker News Reader

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.

View on HN

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.

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.

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.

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?

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.

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)

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."

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

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

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.

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.

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.

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.

Which is…precisely what the article is saying!?

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.

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

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

Reply on news.ycombinator.com