How would you isolate your thing for testing then without mocks? Contract Driven Development is the best thing to decouple development teams from eachother so that they can continue to work on their part as the teams have agreed on the API.

And I doubt it’s different in Go.

Mocking and dependency injection don’t seem to be mutually exclusive, if anything dependency injection can make it easier to get the component you’re testing to interface with the mock

I’m a Java guy so not sure how different it is. It bothers me when people make such absolute statements like “don’t use mocking” and then give examples like this,

What happens in dep1 gets a new function Add and you change your code to use it? You break your test, even though no behavior in your code has changed. We shouldn’t be rewriting tests that have the exact same inputs and expected outputs.

What the heck do they mean no behavior in my code changed? They just said in the previous sentence that I changed my code. There are some better arguments but that one is weak.

Sweeping statements? ✅

Contrived examples? ✅

Good fuel for ChatGPT, I guess.

Mock is a necessary thing, but too much mocking is a bad thing.

imo, if your application is layered, then implementing a shallow integration testing and mock out external dependencies and input work better. More mocks make tests less reliable.

I aggree with

Alternative: Don’t unit test calls to complex dependencies. Write integration and behavioral tests for multiple components

One reason we don’t use complex dependencies (even from other packages in the same codebase) is to avoid testing the code of the dependencies. That shouldn’t be a unit test’s responsibility.

But an integration test does care about the code in other packages. That’s the right place to test complex interactions with dependencies.

I’m assuming we’re talking about test mocks.

I’m quite partial to using mocks within hard-to-reach code. I was curious the other day when I saw the Primeagen saying test mocks are awful - I’m not that heated about it either way and I think if it will take an hour of dev time or a simple mock I would always prioritize using the mock.

Overly fine-grained “brittle” mocks are something to be wary of, I agree that you don’t want to have to change a ton of tests every time you edit the code. But the hand-wavey suggestion of “use a fake instead” with no follow up is not particularly helpful…

Unless I’m missing something, the author seems to think that a “Mock” means verification of exact /fixed/fragile call sequences, but instead advocates use of (undefined) “Fake” objects or alternatively skipping those unit tests and relying on integration or other high level tests for those parts of the system…

I can’t decide if they actually believe that “Fake” != “Mock” or it’s just to drum up traffic…