Hooks in React are a new, popular, and extensible way to organize side-effects and statefulness in React components. By composing the base hooks provided by React, developers can 

 have distributed custom hooks to access your app's store, client, and themes using the 

It's powerful. It's simple. These two statements are not a coincidence, either: the power is the simplicity.

The same goes for testing custom React hooks. By the end of this write-up, you'll think testing hooks as simple, too. We'll learn about React hooks, React in general, some basics of unit testing, and the bigger picture when it comes to automated testing.

React hooks are not quite normal functions. They need to run in a React render context, otherwise, they will give you an annoying error. Other literature on this topic suggests building a React component in the test and hacking that to test your hook's functionality using component testing tools like Enzyme. I found this approach to be brittle (who wants to maintain an unused component for every hook change?) and unnecessary.

. It makes testing React hook behavior, parameters, and return values a breeze. Much easier than dealing with Enzyme, for example.

 utilities. The first is where to specify your React Hook, context, and parameters. For instance, here is how to set up and test a React hook's parameters and return value.

        const { result } = renderHook(() => useTime(100));

        expect(result.current).toBe('mockNow');

 utility is for triggering side-effects for your hook to respond, like events or changing props. It is the same as the 

. We'll see it in action later when we learn (spoiler alert) time control.

Mocking is like the beginning of an Indiana Jones movie. It's like filling a bag with sand so when we swap the sandbag with the treasure, the detector doesn't trigger the trap.

The detector has to not see the difference between the mock and the real thing. For example, you can mock 

 so your hook does all the steps to send an HTTP request without actually sending a request. Plus, because you control the mock of 

, you can decide when the promise resolves or rejects.

In React, dependencies can be your package.json dependencies or the exports of other source modules through import/requires, provided through context, or defined elsewhere in the file. If your hook 

When it comes to testing anything, from a web application to - yes - a React hook, there are different levels at which we can test. The core question of automated testing is this: how much should we mock? If we mock too many dependencies, we lose confidence that the system works as a whole. However, if we mock too few, the sheer number of moving parts cause our tests to be slower, less reliable, and harder to debug/pinpoint failures. If you want to learn more about managing software quality and automated testing, check out these 

The prevailing wisdom is to have more small tests with mocks and a few large and valuable end-to-end tests.  This is often visualized using a pyramid, called the "testing pyramid". In essence, most of your tests should mock a lot (unit tests), then some tests should mock less and ensure lower-level units are wired up together properly (integration tests), and then fewer tests mock even less and ensure the mid-size units interact properly (also integration tests). At the top of the pyramid, tests should have no mocks yet be very few in number (end-to-end tests).

To use another analogy: if you were testing a car, you would test if the sparkplug works, then make sure the assembled piston works after testing its parts, then make sure the engine works after testing its parts, then make sure the whole car starts and survives a lap around the track after testing the gearbox, chassis, brakes, etc.

What does this have to do with testing React hooks?

Your hooks rely on dependencies to get almost anything done. Maybe your hook reads state from a Redux store, or perhaps your hook triggers HTTP requests or GraphQL queries. When unit testing React hooks, you want to avoid depending on anything outside of your UI code, like backend or browser APIs. That way, your tests failing means the problem is with the UI and not somewhere else.

Test frameworks give the ability to create mock functions. I find 

 (same idea, different terminology) does a nice job teaching this concept and showing examples. In Jest, the key is 

mocking allows us to fashion a fake function or object

 without calling the true implementation, avoiding unwanted side-effects. 

For example, if I have a class controlling an alert noise in my application, I can call 

 to have that function call, when tested, not try to make a real noise. If the method is supposed to return a boolean to indicate success/failure, you can do 

 on the end of a mock to have the mocked function return true for this test.

The hard part about stubbing/mocking is getting access to the dependency so we can 

 it or so we can replace it entirely with a mock. 

The rest of this article is about several ways to inject our mocks into a React hook.

Make Hook Pure, Pass Mocks Through Parameters

In pure functions, all dependencies are passed as arguments to the function. The benefit of this approach is it makes providing (injecting) dependencies during tests straight-forward. Outside of testing, if the dependencies are given default values, the original functionality can be preserved.

read the Medium article for implementation details

 parameter is exposed to allow specifying a different function to get the current time. (

import { useEffect, useState } from 'react';
import { getTime } from './getTime';
import { DateTime } from 'luxon';

export interface IUseTimeOptions {
    _getTime: () => DateTime
}
export const useTime = (
    refreshCycleMilliseconds: number = 100,
    // For testing purposes
    { _getTime }: IUseTimeOptions = { _getTime: getTime },
): DateTime => {

 hook thinks it currently is. Instead of mocking the 

 , I can simply pass in a mock function as 

 .  Here's a test where we do exactly that:

import { renderHook } from '@testing-library/react-hooks'
import { useTime } from '.';

describe('useTime (pure)', () => {
    it('should return the current time (mocked through parameters)', () => {
        const now = 'mockNow';
        const _getTime = jest.fn().mockReturnValue(now);
        const { result } = renderHook(() => useTime(100, { _getTime }));

        expect(result.current).toBe(now);
        expect(_getTime).toBeCalledTimes(1);
    });
});


(For this test, the actual return value of _getTime is not critical, so I used a string)

Of course, by specifying a default function, I can avoid specifying the getTime option when consuming the hook in my components. Here's a sample usage of the useTime hook, without any _getTime specified.

import React from 'react';
import { DateTime } from 'luxon';
import { useTime } from '.';

interface ICountdownProps {
    end: DateTime,
}

export const Countdown: React.FC<ICountdownProps> = ({ end }: ICountdownProps) => {
    const now: DateTime = useTime(200); // this countdown will queue a re-render every 200ms.

An alternative way to control/spy/mock an import is to use the Jest module mocking tools (or tools like 

) to inject mocks through the module system.  Just specify the exact string used for require-ing the dependency, then provide your own mock before importing the unit under test.

import { renderHook, act } from '@testing-library/react-hooks'

// Before importing useTime hook
jest.mock('./getTime', () => ({
    getTime: jest.fn().mockReturnValue('mockNow')
}));

import { getTime } from './getTime'; // mocked function
import { useTime } from '.';

describe('useTime (module)', () => {
    it('should return the current time (mocked through module system)', () => {
        const { result } = renderHook(() => useTime(100));

        expect(result.current).toBe('mockNow');
        expect(getTime).toBeCalledTimes(1);
    });
});


While this example works, I find with larger test files it can be prone to mutation by tests and can, as a result of mutation behavior, become more complicated. Tests should be easy.

Dependencies in React can be provided through the React Context API. This is how components connected to Redux store are able to access state, for example. Let's look at a trivial hook which accesses a context to build a URL string based on a configuration object.

import { useContext, createContext } from 'react';

const defaultConfig = {
    baseurl: 'https://localhost:1948',
    env: 'dev',
};

export const ConfigurationContext = createContext(defaultConfig);

export const useResumeURL = () => {
    const { baseurl } = useContext(ConfigurationContext);
    return `${baseurl}/resume/latest.pdf`;
};


import React from 'react';
import { useResumeURL } from '.';

export const ConfigSection = () => {
    const url = useResumeURL();
    return <div>
        <a href={url} target="_blank" rel="noopener noreferrer">Open my resume</a>
    </div>;
}


In our test, we can rely on default context, or we can specify a new context using the 

 to loop in the context's Provider to inject a mock context value. Let's do both:

import React, { FunctionComponent, ReactNode } from 'react';
import { useResumeURL, ConfigurationContext } from '.';
import { renderHook } from '@testing-library/react-hooks';

describe('useResumeURL (context)', () => {
    const makeWrapper = (value: any): FunctionComponent => ({ children }: { children?: ReactNode }) => (
        <ConfigurationContext.Provider value={value}>
            {children}
        </ConfigurationContext.Provider>
    );

    it('should use context provided config', () => {
        const { result } = renderHook(
            () => useResumeURL(),
            {
                wrapper: makeWrapper({ baseurl: '{baseurl}', env: '{env}' }),
            },
        );

        expect(result.current).toBe('{baseurl}/resume/latest.pdf');
    });

    it('should use default config', () => {
        const { result } = renderHook(
            () => useResumeURL(),
        );

        expect(result.current).toBe('https://localhost:1948/resume/latest.pdf');
    });
});


Made a quick testing factory to build wrappers, so future tests would not be tied to a specific set of values. Keeps tests independent, which is a best practice.

Some dependencies can be controlled in unconventional ways. 

 (generally, the concept of time) can be controlled using Jest (

import { renderHook, act } from '@testing-library/react-hooks'

import { useFakeTimers, SinonFakeTimers } from 'sinon';
import { useTime } from '.';

describe('useTime (sinon clocks)', () => {
    let clock: SinonFakeTimers;

    beforeEach(() => { clock = useFakeTimers(); });
    afterEach(() => { clock.restore(); });

    it('should update the time based on refresh rate', () => {
        const { result } = renderHook(() => useTime(100));
        const initialTime = result.current;

        act(() => {
            clock.tick(99);
        });

        // Don't update yet
        expect(initialTime).toEqual(result.current);

        act(() => {
            clock.tick(1);
        });

        // Updated
        expect(initialTime).not.toEqual(result.current);

        expect(result.current.diff(initialTime).milliseconds).toBe(100);
    });

});


Through experimentation, I found the passage of time has to occur inside 

 callbacks for the hook to register the effects properly.

Another common unconventional dependency mock wraps the XMLHttpRequest (XHR) object so you can block and assert on outgoing network requests, plus control the responses and test the resulting behavior (very nice for testing uncommon API failure scenarios).

<h1 data-node-type="titlePlaceholder">Testing Custom React Hooks with Jest</h1><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20191210172504615_testing-custom-react-hooks-with-jest--8372a502.png" attachmentid="fc80744a-1f0e-4646-9766-4f79a09bc569" contenteditable="false" data-width="1200" data-height="640"><div></div></figure><p>Hooks in React are a new, popular, and extensible way to organize side-effects and statefulness in React components. By composing the base hooks provided by React, developers can <a href="https://reactjs.org/docs/hooks-custom.html" rel="noopener noreferrer nofollow">build their own custom hooks</a> for use by others.</p><p><a href="https://react-redux.js.org/next/api/hooks" rel="noopener noreferrer nofollow">Redux,</a> <a href="https://www.apollographql.com/docs/react/api/react-hooks/" rel="noopener noreferrer nofollow">ApolloClient,</a> and <a href="https://github.com/callstack/react-theme-provider" rel="noopener noreferrer nofollow">Callstack</a> have distributed custom hooks to access your app's store, client, and themes using the <code>useContext</code> hook. You can also compose <code>useEffect</code> and <code>useState</code> to wrap API requests <a href="https://medium.com/javascript-in-plain-english/usetime-react-hook-f57979338de" rel="noopener noreferrer nofollow">or wrap the concept of time.</a></p><p>It's powerful. It's simple. These two statements are not a coincidence, either: the power is the simplicity.</p><p>The same goes for testing custom React hooks. By the end of this write-up, you'll think testing hooks as simple, too. We'll learn about React hooks, React in general, some basics of unit testing, and the bigger picture when it comes to automated testing.</p><h2>Where's the Code?</h2><p>Don't panic, it's all <a href="https://github.com/jamesfulford/testing-react-hooks" rel="noopener noreferrer nofollow">right here in GitHub</a>. Give the repo a star before cloning.</p><h2>Running a React Hook</h2><p>React hooks are not quite normal functions. They need to run in a React render context, otherwise, they will give you an annoying error. Other literature on this topic suggests building a React component in the test and hacking that to test your hook's functionality using component testing tools like Enzyme. I found this approach to be brittle (who wants to maintain an unused component for every hook change?) and unnecessary.</p><p>Try using <a href="https://react-hooks-testing-library.com/" rel="noopener noreferrer nofollow">the react-hooks-testing-library</a>. It makes testing React hook behavior, parameters, and return values a breeze. Much easier than dealing with Enzyme, for example.</p><p>Key concepts are the <code>renderHook</code> and <code>act</code> utilities. The first is where to specify your React Hook, context, and parameters. For instance, here is how to set up and test a React hook's parameters and return value.</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-mDlC1" id="cm-mDlC1">        const { result } = renderHook(() =&gt; useTime(100));

        expect(result.current).toBe('mockNow');</textarea></div><p>The <code>act</code> utility is for triggering side-effects for your hook to respond, like events or changing props. It is the same as the <code>act</code> <a href="https://reactjs.org/docs/test-utils.html#act" rel="noopener noreferrer nofollow">provided by React</a>. We'll see it in action later when we learn (spoiler alert) time control.</p><h2>Mocking</h2><h3>What is Mocking? (By Analogy)</h3><p>Mocking is like the beginning of an Indiana Jones movie. It's like filling a bag with sand so when we swap the sandbag with the treasure, the detector doesn't trigger the trap.</p><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20191128062734538_Indiana%20Jones.gif" attachmentid="9160a074-14e6-45bf-aae9-57a1e17a4323" contenteditable="false" data-width="450" data-height="253"><div></div></figure><ul><li><p>The bag is called a mock and is an object or a function similar to the dependency (treasure)</p></li><li><p>The detector is the unit we are trying to test. For this article, it's our React Hook</p></li><li><p>The trap is the unintended side-effect, like sending HTTP requests to a backend server</p></li></ul><p>The detector has to not see the difference between the mock and the real thing. For example, you can mock <code>axios</code> so your hook does all the steps to send an HTTP request without actually sending a request. Plus, because you control the mock of <code>axios</code>, you can decide when the promise resolves or rejects.</p><p>In React, dependencies can be your package.json dependencies or the exports of other source modules through import/requires, provided through context, or defined elsewhere in the file. If your hook <em>depends</em> on it in order to work, then it's a <em>depend</em>ency.</p><h3>The Core Question of Testing</h3><p>When it comes to testing anything, from a web application to - yes - a React hook, there are different levels at which we can test. The core question of automated testing is this: how much should we mock? If we mock too many dependencies, we lose confidence that the system works as a whole. However, if we mock too few, the sheer number of moving parts cause our tests to be slower, less reliable, and harder to debug/pinpoint failures. If you want to learn more about managing software quality and automated testing, check out these <a href="https://docs.google.com/presentation/d/15gNk21rjer3xo-b1ZqyQVGebOp_aPvHU3YH7YnOMxtE/edit#slide=id.g437663ce1_53_98" rel="noopener noreferrer nofollow">2014 slides from Google engineering.</a></p><p>The prevailing wisdom is to have more small tests with mocks and a few large and valuable end-to-end tests.  This is often visualized using a pyramid, called the "testing pyramid". In essence, most of your tests should mock a lot (unit tests), then some tests should mock less and ensure lower-level units are wired up together properly (integration tests), and then fewer tests mock even less and ensure the mid-size units interact properly (also integration tests). At the top of the pyramid, tests should have no mocks yet be very few in number (end-to-end tests).</p><p>To use another analogy: if you were testing a car, you would test if the sparkplug works, then make sure the assembled piston works after testing its parts, then make sure the engine works after testing its parts, then make sure the whole car starts and survives a lap around the track after testing the gearbox, chassis, brakes, etc.</p><h3>What does this have to do with testing React hooks?</h3><p>Your hooks rely on dependencies to get almost anything done. Maybe your hook reads state from a Redux store, or perhaps your hook triggers HTTP requests or GraphQL queries. When unit testing React hooks, you want to avoid depending on anything outside of your UI code, like backend or browser APIs. That way, your tests failing means the problem is with the UI and not somewhere else.</p><h2>How do I mock my hook's dependencies?</h2><p>Test frameworks give the ability to create mock functions. I find <a href="https://sinonjs.org/releases/v7.5.0/stubs/" rel="noopener noreferrer nofollow">the Sinon.js documentation for stubs</a> (same idea, different terminology) does a nice job teaching this concept and showing examples. In Jest, the key is <code>jest.fn()</code> or <code>jest.spyOn()</code> for mocking methods.</p><p>For our purposes, <em>mocking allows us to fashion a fake function or object</em> without calling the true implementation, avoiding unwanted side-effects. </p><p>For example, if I have a class controlling an alert noise in my application, I can call <code>jest.spyOn(NoiseService, 'playLoudHorn')</code> to have that function call, when tested, not try to make a real noise. If the method is supposed to return a boolean to indicate success/failure, you can do <code>.mockReturnValue(true)</code> on the end of a mock to have the mocked function return true for this test.</p><p>The hard part about stubbing/mocking is getting access to the dependency so we can <code>spyOn</code> it or so we can replace it entirely with a mock. </p><p>The rest of this article is about several ways to inject our mocks into a React hook.</p><h3>Make Hook Pure, Pass Mocks Through Parameters</h3><p>In pure functions, all dependencies are passed as arguments to the function. The benefit of this approach is it makes providing (injecting) dependencies during tests straight-forward. Outside of testing, if the dependencies are given default values, the original functionality can be preserved.</p><p>In this <code>useTime()</code> hook (<a href="https://medium.com/javascript-in-plain-english/usetime-react-hook-f57979338de" rel="noopener noreferrer nofollow">read the Medium article for implementation details</a>), a <code>_getTime</code> parameter is exposed to allow specifying a different function to get the current time. (<a href="https://moment.github.io/luxon/" rel="noopener noreferrer nofollow">I used Luxon for handling DateTimes</a>, I like it more than momentjs)</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-mode="text/typescript" data-uniqueid="cm-9TESj" id="cm-9TESj">import { useEffect, useState } from 'react';
import { getTime } from './getTime';
import { DateTime } from 'luxon';

export interface IUseTimeOptions {
    _getTime: () =&gt; DateTime
}
export const useTime = (
    refreshCycleMilliseconds: number = 100,
    // For testing purposes
    { _getTime }: IUseTimeOptions = { _getTime: getTime },
): DateTime =&gt; {</textarea></div><p>Suppose I want to control what time my <code>useTime()</code> hook thinks it currently is. Instead of mocking the <code>Date</code> object or spying on <code>DateTime.local</code> , I can simply pass in a mock function as <code>_getTime</code> .  Here's a test where we do exactly that:</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-eBBXj" id="cm-eBBXj">import { renderHook } from '@testing-library/react-hooks'
import { useTime } from '.';

describe('useTime (pure)', () =&gt; {
    it('should return the current time (mocked through parameters)', () =&gt; {
        const now = 'mockNow';
        const _getTime = jest.fn().mockReturnValue(now);
        const { result } = renderHook(() =&gt; useTime(100, { _getTime }));

        expect(result.current).toBe(now);
        expect(_getTime).toBeCalledTimes(1);
    });
});
</textarea></div><p>(For this test, the actual return value of _getTime is not critical, so I used a string)</p><p>Of course, by specifying a default function, I can avoid specifying the getTime option when consuming the hook in my components. Here's a sample usage of the useTime hook, without any _getTime specified.</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-Vc3Ns" id="cm-Vc3Ns">import React from 'react';
import { DateTime } from 'luxon';
import { useTime } from '.';

interface ICountdownProps {
    end: DateTime,
}

export const Countdown: React.FC&lt;ICountdownProps&gt; = ({ end }: ICountdownProps) =&gt; {
    const now: DateTime = useTime(200); // this countdown will queue a re-render every 200ms.</textarea></div><h3>Mocking Imports</h3><p>An alternative way to control/spy/mock an import is to use the Jest module mocking tools (or tools like <code>proxyquire</code>) to inject mocks through the module system.  Just specify the exact string used for require-ing the dependency, then provide your own mock before importing the unit under test.</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-HQRQ1" id="cm-HQRQ1">import { renderHook, act } from '@testing-library/react-hooks'

// Before importing useTime hook
jest.mock('./getTime', () =&gt; ({
    getTime: jest.fn().mockReturnValue('mockNow')
}));

import { getTime } from './getTime'; // mocked function
import { useTime } from '.';

describe('useTime (module)', () =&gt; {
    it('should return the current time (mocked through module system)', () =&gt; {
        const { result } = renderHook(() =&gt; useTime(100));

        expect(result.current).toBe('mockNow');
        expect(getTime).toBeCalledTimes(1);
    });
});
</textarea></div><p>While this example works, I find with larger test files it can be prone to mutation by tests and can, as a result of mutation behavior, become more complicated. Tests should be easy.</p><h3>Mock React Context</h3><p>Dependencies in React can be provided through the React Context API. This is how components connected to Redux store are able to access state, for example. Let's look at a trivial hook which accesses a context to build a URL string based on a configuration object.</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-MGCip" id="cm-MGCip">import { useContext, createContext } from 'react';

const defaultConfig = {
    baseurl: 'https://localhost:1948',
    env: 'dev',
};

export const ConfigurationContext = createContext(defaultConfig);

export const useResumeURL = () =&gt; {
    const { baseurl } = useContext(ConfigurationContext);
    return `${baseurl}/resume/latest.pdf`;
};
</textarea></div><p>We're going to test <code>useResumeURL()</code>.  Here's a sample usage:</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-ZNywf" id="cm-ZNywf">import React from 'react';
import { useResumeURL } from '.';

export const ConfigSection = () =&gt; {
    const url = useResumeURL();
    return &lt;div&gt;
        &lt;a href={url} target="_blank" rel="noopener noreferrer"&gt;Open my resume&lt;/a&gt;
    &lt;/div&gt;;
}
</textarea></div><p>In our test, we can rely on default context, or we can specify a new context using the <code>wrapper</code> option from <code>@testing-library/react-hooks</code> to loop in the context's Provider to inject a mock context value. Let's do both:</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-TdpCd" id="cm-TdpCd">import React, { FunctionComponent, ReactNode } from 'react';
import { useResumeURL, ConfigurationContext } from '.';
import { renderHook } from '@testing-library/react-hooks';

describe('useResumeURL (context)', () =&gt; {
    const makeWrapper = (value: any): FunctionComponent =&gt; ({ children }: { children?: ReactNode }) =&gt; (
        &lt;ConfigurationContext.Provider value={value}&gt;
            {children}
        &lt;/ConfigurationContext.Provider&gt;
    );

    it('should use context provided config', () =&gt; {
        const { result } = renderHook(
            () =&gt; useResumeURL(),
            {
                wrapper: makeWrapper({ baseurl: '{baseurl}', env: '{env}' }),
            },
        );

        expect(result.current).toBe('{baseurl}/resume/latest.pdf');
    });

    it('should use default config', () =&gt; {
        const { result } = renderHook(
            () =&gt; useResumeURL(),
        );

        expect(result.current).toBe('https://localhost:1948/resume/latest.pdf');
    });
});
</textarea></div><p>Made a quick testing factory to build wrappers, so future tests would not be tied to a specific set of values. Keeps tests independent, which is a best practice.</p><h3>Unconventional Mocking</h3><p>Some dependencies can be controlled in unconventional ways. <code>setTimeout</code> and <code>setInterval</code> (generally, the concept of time) can be controlled using Jest (<a href="https://sinonjs.org/releases/v7.5.0/fake-timers/" rel="noopener noreferrer nofollow">and Sinon.js, used in this example</a>).</p><div data-remotecodeblock="true" class="cm-remoteCodeBlock"><div data-codeeditordecorations="true"></div><textarea data-iscodemirror="true" data-uniqueid="cm-r7bB9" id="cm-r7bB9">import { renderHook, act } from '@testing-library/react-hooks'

import { useFakeTimers, SinonFakeTimers } from 'sinon';
import { useTime } from '.';

describe('useTime (sinon clocks)', () =&gt; {
    let clock: SinonFakeTimers;

    beforeEach(() =&gt; { clock = useFakeTimers(); });
    afterEach(() =&gt; { clock.restore(); });

    it('should update the time based on refresh rate', () =&gt; {
        const { result } = renderHook(() =&gt; useTime(100));
        const initialTime = result.current;

        act(() =&gt; {
            clock.tick(99);
        });

        // Don't update yet
        expect(initialTime).toEqual(result.current);

        act(() =&gt; {
            clock.tick(1);
        });

        // Updated
        expect(initialTime).not.toEqual(result.current);

        expect(result.current.diff(initialTime).milliseconds).toBe(100);
    });

});
</textarea></div><p>Through experimentation, I found the passage of time has to occur inside <code>act</code> callbacks for the hook to register the effects properly.</p><p>Another common unconventional dependency mock wraps the XMLHttpRequest (XHR) object so you can block and assert on outgoing network requests, plus control the responses and test the resulting behavior (very nice for testing uncommon API failure scenarios).</p><h3>For more, follow me on Medium: <a href="https://medium.com/@james.patrick.fulford" rel="noopener noreferrer nofollow">medium.com/@james.patrick.fulford</a></h3>

AUTHOR

James P. Fulford

Hooks in React are a new, popular, and extensible way to organize side-effects and statefulness in React components. By composing the base hooks provided by React, developers can build their own custom hooks for use by others. Redux, ApolloClient, and Callstack have distributed custom hooks to…

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Free Tools

Testing Custom React Hooks with Jest

Tags

Responses (0)

Free AI Career Tools

AI Job Listings

ATS Resume Checker

Startup Perks

Masterclasses

Tutorials

Fullstack React with TypeScript