Mocking a JavaScript class with Jest: mocking vs. dependency injection

Fakes &gt; Mocks!<p>Post: <a href="https:&#x2F;&#x2F;tyrrrz.me&#x2F;blog&#x2F;fakes-over-mocks" rel="nofollow">https:&#x2F;&#x2F;tyrrrz.me&#x2F;blog&#x2F;fakes-over-mocks</a><p>Previous HN Discussion on the above post: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24770954" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24770954</a><p>This does require dependency injection (DI), and my hot take is that manual DI &gt; framework magic. Sure it&#x27;s a little extra code writing, but folks should optimize for reading code, and some of the frameworks out there have a lot of complex concepts for DI (For example dagger is a popular DI framework for JVM, and the dev-guide has a lot of stuff in it, which feels like a lot to learn for what it&#x27;s providing: <a href="https:&#x2F;&#x2F;dagger.dev&#x2F;dev-guide&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dagger.dev&#x2F;dev-guide&#x2F;</a>, no knock against dagger, I&#x27;ve ran into this with other DI frameworks too!)

Perhaps I&#x27;m a masochist but I don&#x27;t find these types of tests valuable.<p>Fuzzing, e2e, property testing, &amp; strict type system seem more worthwhile in my opinion.

Here&#x27;s what I don&#x27;t quite understand about mocking in Javascript.<p>When I write a frontend application using components (React, Preact, web components — doesn&#x27;t really matter), I will often find myself in a situation when I have a component tree like this:<p>A --&gt; B --&gt; C<p>In which I want to test component A; but one of its grand(-grand-etc.-)children down the tree (in this case, component C) is quite complex; and setting up a test for component A in such a way as to accommodate for the dependencies of component C would be cumbersome.<p>Normally, I would just mock component C out entirely, using Jest&#x27;s module mocking ability. However, this comes at a cost. ES6 import statements are static; and thus, when Jest finally completes its transition to ES6 modules, it won&#x27;t be able to just mock plain static imports. The likely solution is that the rules for mocking will change; and if one wants to mock modules, he would have to do so via dynamic imports. Which means I&#x27;ll have to go through all my tests and rewrite them :-(<p>I have not yet seen a good and clean story for mocking Javascript modules. A more standards-compliant project, Web Test Runner, does module mocking via import maps [0]; but this looks both clunky and not quite suited for per-test mocking.<p>Which leaves me confused. If mocks are evil, how do I test my components? And if they are fine, what&#x27;s the future-proof standards-compliant way of module mocking in Javascript?<p>0 - <a href="https:&#x2F;&#x2F;modern-web.dev&#x2F;docs&#x2F;dev-server&#x2F;plugins&#x2F;import-maps&#x2F;" rel="nofollow">https:&#x2F;&#x2F;modern-web.dev&#x2F;docs&#x2F;dev-server&#x2F;plugins&#x2F;import-maps&#x2F;</a>

Why can&#x27;t we just &quot;make fun&quot; of JavaScript classes with &quot;jokes?&quot;

In all the tests I&#x27;ve written mocking always sucks. It&#x27;s not hard, but it becomes a rabbit whole time suck.<p>My personal goal is to only mock the server and as low as possible or necessary.<p>I&#x27;m fully convinced mocking is a code smell of a bad implementation. It means the abstraction is leaky or too complex and would be better off being broken further down. I also abide by the rule of not exporting or making something public just for the sake of testing it.<p>Property tests are useful but can be tricky to identify, and a good type system that is well used removes the need for the majority of unit tests. No more, validate this function returns a number, or a string. The compiler will test and guarantee that for you.<p>Invoke the function under test and assert on its return value. This works in the majority of cases but when you do need to reach for something stronger, JS can do some fun stuff via reflection.<p>An example.<p>We want to test a function that consumes an object which is used to make an HTTP fetch call, building the `Request` object from the passed object.<p><pre><code> &#x2F;&#x2F; Of course we mock the fetch function &#x2F;&#x2F; or would have a mock server running via something like msw. &#x2F;&#x2F; Tests should never require an internet connection to run. window.fetch = jest.fn().mockResolveValue(new Response()); const config = { url: &#x27;https:&#x2F;&#x2F;myapi.com&#x27; }; &#x2F;&#x2F; Invoke the function under test await myFunctionThatInvokesFetch(config); &#x2F;&#x2F; We can access the mocked fetch function and get the argument with which it was called - &#x2F;&#x2F; the built up Request object from the argument passed to the function under test. const requestObjectUsed = window.fetch.mock.calls[0][0]; const realRequestObject = new Request(requestObjectUsed); &#x2F;&#x2F; Validate that if no method is specified in config, we default to a GET request. expect(realRequestObject.method).toBe(&#x27;GET&#x27;); </code></pre> Lastly, if a function modifies one of its arguments, the function should include that modified value as part of it&#x27;s return value. The same could be said for having a function invoke other functions. Rather than assert a function is called, have it return something that indicates it was called.<p>This makes testing a breeze and is also a hint to the invoker that something was done to the thing passed to it.

I like using redux: no mocking necessary. Everything is just functions, completely trivial to test. If you use redux-saga you can even test async flows without mocking anything like server responses, browser apis and so on.

I just cannot for the life of me ever understand a test with mocks in.<p>Mocking things at the module level seems incredibly convoluted to me. You constantly go off and look at where the imports are coming from and trying to keep all that in line.