Testing custom hooks in React can be a tricky business, but it’s essential for ensuring your app’s reliability. Let’s dive into some lesser-known Jest techniques that’ll make your life easier when it comes to putting those hooks through their paces.
First things first, we need to set up our testing environment. Make sure you’ve got Jest and React Testing Library installed. If not, run:
npm install --save-dev jest @testing-library/react @testing-library/react-hooks
Now, let’s say we’ve got a custom hook called useCounter that increments a counter. Here’s what it might look like:
import { useState } from 'react';
function useCounter(initialCount = 0) {
const [count, setCount] = useState(initialCount);
const increment = () => setCount(prevCount => prevCount + 1);
return { count, increment };
}
export default useCounter;
To test this hook, we’ll use the renderHook function from @testing-library/react-hooks. This nifty little helper lets us render our hook in a test environment:
import { renderHook, act } from '@testing-library/react-hooks';
import useCounter from './useCounter';
test('should increment counter', () => {
const { result } = renderHook(() => useCounter());
act(() => {
result.current.increment();
});
expect(result.current.count).toBe(1);
});
Pretty straightforward, right? But what if our hook depends on context? That’s where things get interesting. Let’s say we have a theme context and our hook uses it:
import { useContext } from 'react';
import { ThemeContext } from './ThemeContext';
function useTheme() {
const theme = useContext(ThemeContext);
return theme;
}
export default useTheme;
To test this, we need to wrap our hook in the context provider. Here’s a trick: we can create a wrapper component to do just that:
import { ThemeContext } from './ThemeContext';
const wrapper = ({ children }) => (
<ThemeContext.Provider value={{ color: 'blue' }}>
{children}
</ThemeContext.Provider>
);
test('should use theme from context', () => {
const { result } = renderHook(() => useTheme(), { wrapper });
expect(result.current.color).toBe('blue');
});
Cool, huh? But we’re just getting started. What about hooks that fetch data? Enter Jest’s mocking capabilities. Let’s say we have a hook that fetches user data:
import { useState, useEffect } from 'react';
function useUser(id) {
const [user, setUser] = useState(null);
useEffect(() => {
fetch(`/api/users/${id}`)
.then(res => res.json())
.then(data => setUser(data));
}, [id]);
return user;
}
export default useUser;
To test this, we can mock the fetch function:
global.fetch = jest.fn(() =>
Promise.resolve({
json: () => Promise.resolve({ id: 1, name: 'John Doe' }),
})
);
test('should fetch user data', async () => {
const { result, waitForNextUpdate } = renderHook(() => useUser(1));
await waitForNextUpdate();
expect(result.current).toEqual({ id: 1, name: 'John Doe' });
});
Now, what if our hook uses a timer? Jest has us covered with its timer mocks. Let’s create a hook that debounces a value:
import { useState, useEffect } from 'react';
function useDebounce(value, delay) {
const [debouncedValue, setDebouncedValue] = useState(value);
useEffect(() => {
const timer = setTimeout(() => setDebouncedValue(value), delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debouncedValue;
}
export default useDebounce;
To test this, we can use Jest’s fake timers:
jest.useFakeTimers();
test('should debounce value', () => {
const { result, rerender } = renderHook(
({ value, delay }) => useDebounce(value, delay),
{ initialProps: { value: 'hello', delay: 1000 } }
);
expect(result.current).toBe('hello');
rerender({ value: 'world', delay: 1000 });
jest.advanceTimersByTime(500);
expect(result.current).toBe('hello');
jest.advanceTimersByTime(500);
expect(result.current).toBe('world');
});
Pretty cool, right? We can control time itself in our tests!
Now, let’s talk about testing hooks that use Redux. If you’re using Redux with hooks, you might have a custom hook that selects data from the store. Here’s how you can test it:
import { renderHook } from '@testing-library/react-hooks';
import { Provider } from 'react-redux';
import configureStore from 'redux-mock-store';
import useSelectUser from './useSelectUser';
const mockStore = configureStore([]);
test('should select user from store', () => {
const store = mockStore({
user: { id: 1, name: 'John Doe' },
});
const wrapper = ({ children }) => (
<Provider store={store}>{children}</Provider>
);
const { result } = renderHook(() => useSelectUser(), { wrapper });
expect(result.current).toEqual({ id: 1, name: 'John Doe' });
});
This approach lets you test your hook’s interaction with Redux without setting up a full Redux environment.
Speaking of complex setups, what if your hook uses multiple contexts and maybe even a Redux store? No problem! We can combine multiple wrappers:
const reduxWrapper = ({ children }) => (
<Provider store={store}>{children}</Provider>
);
const themeWrapper = ({ children }) => (
<ThemeContext.Provider value={{ color: 'blue' }}>
{children}
</ThemeContext.Provider>
);
const allTheWrapper = ({ children }) => (
<reduxWrapper>
<themeWrapper>{children}</themeWrapper>
</reduxWrapper>
);
test('should work with all the things', () => {
const { result } = renderHook(() => useMyComplexHook(), {
wrapper: allTheWrapper,
});
// ... assertions here
});
Now, let’s talk about something that often trips people up: testing hooks that use the useRef hook. The tricky part is that refs don’t cause re-renders, so we need to be a bit clever:
function useRefExample() {
const ref = useRef(0);
const incrementRef = () => {
ref.current += 1;
};
return { ref, incrementRef };
}
test('should increment ref', () => {
const { result } = renderHook(() => useRefExample());
act(() => {
result.current.incrementRef();
});
expect(result.current.ref.current).toBe(1);
});
See what we did there? We’re directly accessing the ref’s current value in our assertion.
Now, here’s a fun one: testing hooks that use the useReducer hook. It’s like testing a mini Redux store:
function reducer(state, action) {
switch (action.type) {
case 'INCREMENT':
return { count: state.count + 1 };
case 'DECREMENT':
return { count: state.count - 1 };
default:
return state;
}
}
function useCounter() {
const [state, dispatch] = useReducer(reducer, { count: 0 });
return { state, dispatch };
}
test('should handle actions correctly', () => {
const { result } = renderHook(() => useCounter());
act(() => {
result.current.dispatch({ type: 'INCREMENT' });
});
expect(result.current.state.count).toBe(1);
act(() => {
result.current.dispatch({ type: 'DECREMENT' });
});
expect(result.current.state.count).toBe(0);
});
This approach lets you test complex state logic in isolation.
Lastly, let’s talk about testing hooks that use React’s new concurrent features. These can be tricky because they introduce non-deterministic behavior. Here’s a hook that uses useDeferredValue:
import { useState, useDeferredValue } from 'react';
function useDeferredSearch(initialQuery = '') {
const [query, setQuery] = useState(initialQuery);
const deferredQuery = useDeferredValue(query);
return { query, setQuery, deferredQuery };
}
test('should defer value update', async () => {
const { result, waitForNextUpdate } = renderHook(() => useDeferredSearch());
act(() => {
result.current.setQuery('new query');
});
// The deferred value doesn't update immediately
expect(result.current.deferredQuery).toBe('');
// Wait for the deferred update
await waitForNextUpdate();
expect(result.current.deferredQuery).toBe('new query');
});
This test demonstrates how we can handle the asynchronous nature of deferred values in our tests.
And there you have it! A deep dive into testing custom hooks with Jest. Remember, the key to good tests is not just covering all the cases, but also making your tests readable and maintainable. Happy testing!
