Don't Use Mocks

Can we not have articles like this with blanket statements like this please? As with everything in software, no one size fits all. Mocks have their place. There are situations when the only way we can test something out is to mock out a certain function call. Sometimes our dependencies are so complex and deep that we cannot just replace it with a fake. But with a little mock we can replace a function or a class within that dependency to decouple our tests from it.<p>Having a title with a blanket statement like &quot;Don&#x27;t Use Mocks&quot; is either plain wrong or clickbait. In this case, it seems it is both wrong and clickbait. Such blanket statements and clickbaits specifically trigger people to get into a long-winded debate (ironically, my own comment here is a case in point) about something that is obvious and otherwise uncontroversial.

The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled and brittle. Almost any change in the implementation will require changing such tests. And by their nature, they probably test some minor low-level things, that are not all that valuable to assert anyway. Mocks enable and encourage this kind of testing.<p>Better tests would assert some kind of higher level properties that are much less likely to change. This often involves making the dependencies you inject during testing some more complete simulations of real implementations. Takes more up front effort to implement them, but can often be re-used between many tests.<p>Tests on one hand help you modify software over time, but on the other hand increase maintenance burden. Being good at testing doesn&#x27;t mean just writing lots of tests, but being good at judging the value of a test vs the cost of having it, which is very context dependent in itself.

There are entirely separate communities IMO when it comes to automated tests.<p>There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing.<p>And there are the folks who write convoluted tests that, when you dig into them, just confirm that String&#x27;s .equals() works OK. DAO&#x2F;database tests which have mocking going on to the point where you&#x27;re faking a database response of &quot;hello&quot;, say, and then checking &quot;expected response == hello&quot;. Then yay our test passes!!<p>Personally I feel our energy should somehow be spent collectively on getting the latter group to just not write <i>total garbage</i>, and that the bar for &quot;good enough&quot; is really not that high, after which we get into diminishing-returns territory. And I think, personally, that mocking is responsible for so much confusion in folks that ultimately don&#x27;t really know what they&#x27;re trying to accomplish.

Such a bad take IMHO. Sorry.<p>1. You still need to update the fake object once you gonna add a new behaviour.<p>2. Fake object has a tendency to become logic heavy. Someone will add a stupid-not-needed-map to test some shit you don&#x27;t need to test in this unit\layer.<p>3. You only need to mock the behaviour you depend on. If you&#x27;ve added new Method and you need to mock it despite the fact you&#x27;re not using it in the code you&#x27;re testing - its a bit weird and smelly. Consider rethink SOLID principles at least.<p>4. Go. Gen. Effectively you can automate mock generation. Debatable but it&#x27;s cool.<p>Just. Keep. Things. Simple. Depend on what you need. Mock behaviour you need. Try to test flattened structure - do not test the layer below the one you&#x27;re testing ATM (unit tests).

I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic then you are probably mixing up your business level code with side-effecting code (like calling APIs or DBs).<p>Personally I&#x27;ve found it better to split pure business logic and side-effecting logic as close to the edge (API endpoint handler) as possible. Then it is trivial to see where side-effects happen and you get to easily write unit tests for the business logic that matter.<p>Mocking is mostly always a pain and I would rather not mock at all and do proper end-to-end for integration code if possible.

The topic of software theory (articles, advices, recommendations) for testing is the biggest failure of this industry<p>Everyone is trying to figure out how to do it &quot;right&quot;(measuring by their needs)<p>and all of them struggle to realize that it is always context dependent - two different products, teams, companies may have different expectations and needs<p>I dont know how this happens that out of all arguable things in software engineering - is it that tests are the most chaotic ones, when up to the principle they are simple: if your code doesnt match specification, then scream!<p>Dont even get me on how TDD saves the world and is the only way how all software should be written (it is especially funny that tdd is accidentally successful by forcing api design first, yet ppl always argue for it due to red green transition and never due to api design first)<p>Also the concept of unit as in unit test may differ by kind of software<p>E.g unit test for parser may feel like e2e test for somebody who works in web apps

This topic of testing techniques is fraught with extreme points of view. The way I see it is that unit testing, int-testing, mocks, stubs, and now fakes are all techniques and tools in your toolbox. Do not throw out a tool in favor of always using one of them. Instead, I implore devs, to try and use the *best tool for the job at the time for a specific test. Understanding that &quot;best&quot; is based on opinions and current constraints at the time. I would implore exploration, and experiments to try these different tools to get a better understanding of their pro&#x27;s and limitations.

Nah I&#x27;m about done working on rails codebases with 2+ hour CI cycles because developers insist on hammering a database in unit tests.

I&#x27;m not sure I follow the argument. Use fakes instead of mocks, but if you change the dep1 to have a method add instead of addone, you still need to update the fake. The effect is the same as if you needed to update the mock setup. About the only benefit I can see, is if the fake is used in multiple tests and you only need to update it once.

This misses the point. It briefly touches the point, then . . . facepalm.<p>If you test behaviors, either with mocks or with fakes, you&#x27;re not tied to implementation details. I can only assume this stops things from being what the author calls &quot;brittle.&quot;<p>If your test doesn&#x27;t test a behavior, then you are testing (at best!) an implementation detail. So maybe remove the test. If you&#x27;re looking at code coverage, you should be able to get complete coverage testing at this level without testing implementation details or . . . you&#x27;ve found dead code - remove that, too! Tell your boss what a wise greybeard you must be because your commits remove bad things.<p>Whether or not you test behaviors, there are more running processes with fakes. There&#x27;s a lot more happening that can fail. I&#x27;d call that brittle. Fakes have their place, but the reason to use them is because they&#x27;re much less brittle (prone to fail) than full-stack end-to-end tests are. You can spin up your new microservice with all of its shared-nothing data stores, surround it with fakes, and completely exercise all of its reachable code - code like those error paths that are hard to hit otherwise. Better to test as much as you can in isolation first - faster feedback, easier to diagnose failures, and less test maintenance than a deployed environment.

I mostly agree, but with one exception - I think mocks are still useful for RPCs to other systems, where you want to test that you:<p>1) Call the right method on the interface with the right data, and<p>2) Correctly handle different return values from the RPC.<p>If you change your code to call a different RPC method your test _should_ fail, I&#x27;d argue that&#x27;s exactly the point of this sort of test.<p>On the other hand, for testing code that you entirely control, I 100% agree that a fake would provide a better test,

Where I have found mocking useful or unavoidable is when we need to modify behaviour that is not in our control. This almost always is in calling a third party resource (api or store) or an sdk or library.<p>Everything else can be controlled and tested via DI.

I agree with the premise and have taken a deeper dive (<a href="https:&#x2F;&#x2F;github.com&#x2F;osmyn&#x2F;Practices&#x2F;blob&#x2F;master&#x2F;UnitTestGuidelines.md">https:&#x2F;&#x2F;github.com&#x2F;osmyn&#x2F;Practices&#x2F;blob&#x2F;master&#x2F;UnitTestGuide...</a>) if anyone is interested in learning more about creating tests that aren&#x27;t brittle. I did this after suffering through poorly written tests that made our team afraid of any refactoring.

My goto simple example here for dumb mocks is a multiply function.<p>You are doing it wrong if you have:<p>MyMock.Mocks(myMultiplyFunc).WithArgs(3, 4).ToCall(myAddFunc).Times(3).WithArg(4).ExpectsResponse(12).<p>Your multiply func being backed by add is not important to the unit test for multiplying. If you change it to have special handling for bitshifting in different cases, your mock tests break. Badly.<p>Mocks add coupling. Coupling is brittle. There are other testing options available. Are mocks sometimes useful? Maybe. I&#x27;ve not needed a mock library in 10 years of Go development designing and building robustly tested distributed sytems at scale. Every time I&#x27;ve seen a mock used it is gross. You end up with SomeSAASMock that is auto-generated to provide all the special handling of the real calls to the SAAS.<p>Don&#x27;t mock out the full SendGrid API. Make a dependency interface &quot;SendEmail(userID int, content []byte) (SendGridResp, error)&quot;. Inject that. Now you just have MyFakeSendGrid structs in tests and you can have it return an error when you want, or not. It is really that simple.<p>Depending on how detailed your integration or acceptance tests are, you can have sinks that capture network calls and return stubbed data or call the actual service.

I think this one is context dependent.<p>If you are a small or medium project that doesn&#x27;t make many RPCs just test with the real thing.<p>Once I got to google which makes many RPCs in every layer it just wasn&#x27;t viable to not use mocking. I use mocks in almost every thing.<p>Yes, it makes unit tests brittle and couples to implementation. But unit tests are cheap and often need to be changed anyways. It also allows you to have control over certain situations like what happens if an error occurs. Which can be hard to test for in integration tests.<p>In short I feel like avoid mocks if you can but embrace them if you can&#x27;t.

This article is extreme, in the case of Java (mockito), using mocks is a great way to infer the path the logic takes.<p>If anything mocking is useful for verifying that something is called whether that be a service or a repository method.<p>Equally mocking things like mappers is overkill, a nice balance is to inject some mocks and some &quot;real&quot; instances of dependencies into the class that is under test.<p>The added benefit is that you are testing the dependencies (if the mapper for example) are working.

A very good way to use mocks (not like illustrated here) is explained in the GOOS book by Freeman and Pryce: <a href="http:&#x2F;&#x2F;www.growing-object-oriented-software.com&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.growing-object-oriented-software.com&#x2F;</a>

Does anyone know if there are libraries for writing fakes ? I wonder why there is a lot of mock libraries but I know none for writing fakes.