Mocking function calls within a module

JEST logo

Let’s say you have the file:

// f.jsexport function b(){
return 'b';
export function a(){
return b();

If you want to mock b to test a, well… It is not as easy as it seems to be.

The Naive Approach

What I initially tried to do was:

test('a', () => {
const f = require('./f');
jest.spyOn(f, 'b').mockReturnValue('c'); expect(f.a()).toBe('c');
// expected 'c' got 'b'

Nope… It won’t work.

That is because the exported b is mocked indeed, but it’s not the same b as the one that is called by a inside the module.

Solution 1 — Splitting The Module Into Different Files

If you move b

Sometimes we respond to React element mounts. The first instinct is to useRef & useEffect. But It’s wrong. What you really need is often useCallback.

setRef returned from useCallback

If you want to respond to a React element’s mounting on the DOM, you may be tempted to use useRef to get a reference to it and useEffect to respond to its mounts and unmounts. But it won’t work.

This is because there is no callback or re-render when a component is (un)mounted and attached to ref.current using useRef.

The react-hooks eslint rules would even warn you about that. Notice how neither ref nor ref.current as deps of useEffect trigger it.

How can you run tests on version X and version Y of a library, with real-world examples of testing React 16 and React 17

With the release of React 17, many React library maintainers found themselves wondering:

“Should I test only React 17 from now on, or maybe should I stick to React 16 until version 17 will be more widely adopted by the community?”.

I’ve certainly found myself in this situation with my library Why Did You Render.

I decided to find a way to test both of the versions since my library deals with patching React ( don’t try this at home :P ) and works a little differently for each of the versions.

By the way, if you like the article,

React.memo / React.PureComponent usage guide

What’s a Pure Component?

(Official docs: React.PureComponent, React.memo)

In the following example, when App re-renders,
<Main userName={userName}/> and <Header/> are called:

And they always return new React Elements.

Remember that JSX is just syntax sugar for React.createElement (in React 17 it’s equivalent mostly conceptually) so App‘s code is equivalent to:

Usually, as a result of creating React Elements, they also re-render, so their code will run.

If they are pure, however, they only re-render when any of their props change, otherwise React re-uses the last rendered result.

In our case, a pure Header would never re-render because it has no props.


What is issue #14099 in React’s repo and how it affects you?

Why do we need useCallback in the first place?

In the official documentation of useCallback it says:

“This is useful when passing callbacks to optimized child components that rely on reference equality to prevent unnecessary renders”

In the following example, PureHeavyComponent would re-render every single time that the Parent component is re-rendered although PureHeavyComponent is pure because previous props.onClick !== new props.onClick, because a new onClick function is created on every render of Parent.

A naive code where a pure heavy component is re-rendered on every re-render of its parent.

Since PureHeavyComponent is “heavy” we want it to re-render as less as possible. This is why we made it…

When working remotely, you benefit much more from good working processes and proactive team members and you are punished much more severely for sloppy work processes and personal carelessness

When I heard about the possibility of working from home some 8 years ago at Welldone Software (recently merged with CodeValue), I had no idea what that meant. It even sounded pretty weird to me. How could my boss help me, and guide me? How will he know what I was working on? How do we coordinate and plan what works? And what about working in large teams?

Fortunately, I decided to go for it, and today the answers to these questions are clear to me, as is the power this format has. Having worked in “open space” for about…

This guide is intended to catch you up with the most important reasoning, terms, tools, and approaches to JavaScript testing for the year 2021.

It combines information from the best articles recently released (they are referenced at the bottom) and adds from my own experience at Welldone Software, where we have implemented different testing solutions for different products over many years.

It’s a little long but whoever reads and understands this guide, can safely assume they know the overall state of JavaScript testing in the web development community.

Just a couple of years ago website testings had very little documentation…

TypeScript support, Custom hooks tracking (like React-Redux’s useSelector), Tracking of all pure components.

So what’s new in @welldone-software/why-did-you-render v4?

TypeScript Support

Typing for all the different scenarios of the library are now supported.

Improved Overall Stability

Tests are now covering more scenarios than ever, including integration with libraries, and there are no significant open issues.

Tracking of all Pure Components

The trackAllPureComponents option makes the library track all pure components.

Using this option is very convenient because now you don’t need to explicitly set whyDidYouRender = true on components (although you still can). Instead, you can assume all pure components needs to tracked, and to be as efficient as possible without redundant re-renders.

Notice: you can turn off whyDidYouRender anytime for specific components…

A key concept of React we tend to forget, quickly explained.

How come a React element’s parent might not be the one who renders it?

When I debug functionality and performance in a React app, I always keep in mind the difference between who created a certain element vs. it’s parent vs. the reason for it’s render. I would like to share my experience in this regard with you.

Meet App, Parent, and Child. They would be the React components we use to understand React life-cycle a little bit better using the following sandbox.

The React components we are going to work with.

When App (re-)renders, the flow is as follows:

1. Child elements are created by App and passed to the element creation of…

All you need to know about your role as a developer to improve your website’s position in Google search results.

The most important thing in getting a good rank in Google is to make your website engaging, useful, and original. Your role as a developer is to ensure it is accessible and smooth for users and correctly exposed to Google bots.

Let’s talk about what it takes to appear on the fabled top position on Google.

The Dream — Top Result on Google

What is SEO?

SEO means Search Engine Optimization. It’s a set of guidelines that are supposed to make your site appear higher than others on Google search results. Specifically for organic (unpaid) search results.

We focus on Google in this article because it is by far the…

Vitali Zaidman

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store