DEV Community

Cover image for TDD with MSW for a Custom Fetch React Hook
Matti Bar-Zeev
Matti Bar-Zeev

Posted on

TDD with MSW for a Custom Fetch React Hook

#react #testing #javascript #webdev

On my recent published article on the subject I got a request to go through a process of creating a custom React hook using TDD, but for a hook which has server interactions:

Image description

Challenge accepted 🤓
Well maybe “half accepted” since in this article you will be joining me as I create a custom hook which only does the fetching from the server, but I believe it will lay down the foundations for extending it to other hook-to-server interactions.

In this one I will be using MSW (Mock Service Worker) which is a pretty cool solution for mocking API's for tests.

As always I start from the basic requirements:

  • This custom Fetch hook should
    • Fetch data from a given URL
    • Indicate the status of fetching (idle, fetching, fetched)
    • Have the fetched data available to consume

Let’s start :)

My hook’s name is going to be, surprisingly enough, “useFetch”.

I crank up Jest in a watch mode, and have my index.test.js ready to go. The first thing to do is to check if this hook even exists:

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

describe('UseFetch hook', () => {
   it('should exist', () => {
       const {result} = renderHook(() => useFetch());
       expect(result.current).toBeDefined();
   });
});
Enter fullscreen mode Exit fullscreen mode

Well you guessed it, it does not. Let’s create the index.js file for this hook and the minimum required for satisfying the test:

const useFetch = () => {
   return {};
};

export default useFetch;
Enter fullscreen mode Exit fullscreen mode

I’m returning an empty object at the moment cause I really don’t know yet how the returned values will be formatted, but an object is a good start.

The first thing I would like to tackle is the “idle” status.
This status is being returned when no “url” was given to the hook and thus it stands… idle. My test is:

it('should return an "idle" status when no url is given to it', () => {
       const {result} = renderHook(() => useFetch());
       expect(result.current.status).toEqual(IDLE_STATUS);
   });
Enter fullscreen mode Exit fullscreen mode

And here is the code to satisfy it.

NOTE: As you can see I’m jumping some refactoring steps on the way (which you can read about in more details on my previous article) - I’ve create a inner state for the status and also exported some status constants, but if I were to follow the strict TDD manner, I would just return a hard-coded status from the hook which would satisfy the test above as well

import {useState} from 'react';

export const IDLE_STATUS = 'idle';
export const FETCHING_STATUS = 'fetching';
export const FETCHED_STATUS = 'fetched';

const useFetch = ({url} = {}) => {
   const [status, setStatus] = useState(IDLE_STATUS);

   return {
       status,
   };
};

export default useFetch;
Enter fullscreen mode Exit fullscreen mode

Now it is getting interesting -
I would like to check that when the hook receives a url argument it changes it status in the following order: idle -> fetching -> fetched
How can we test that?

I will use the renderHook result “all” property, which returns an array of all the returned values from the hook's update cycles. Check out the test:

it('should first go into an "idle" status and then "fetching" and then "fetched" when initiated with a URL', () => {
       const {result} = renderHook(() => useFetch({url: mockUrl}));
       expect(result.all.length).toEqual(3);
 expect(result.all[0].status).toEqual(IDLE_STATUS);
       expect(result.all[1].status).toEqual(FETCHING_STATUS);
       expect(result.all[2].status).toEqual(FETCHED_STATUS);
   });
Enter fullscreen mode Exit fullscreen mode

Notice that I make sure that there are 3 update cycles of the hook. My test fails obviously since my hook does not do much now, so let’s implement the minimum to get this test passing. I will use the useEffect hook to tap to the url initialization and changes and make my state transitions there in a very naive manner:

const useFetch = ({url} = {}) => {
   const [status, setStatus] = useState(IDLE_STATUS);

   useEffect(() => {
       setStatus(FETCHING_STATUS);
       setStatus(FETCHED_STATUS);
   }, [url]);

   return {
       status,
   };
};
Enter fullscreen mode Exit fullscreen mode

Hold on, I know. Hold on.
Well, I have now 2 tests which fail - the first is the test I wrote for the “idle” status since the status is no longer “idle” when there is url, so I need to make sure that if there is no url the useEffect will not do anything:

const useFetch = ({url} = {}) => {
   const [status, setStatus] = useState(IDLE_STATUS);

   useEffect(() => {
       if (!url) return;
       setStatus(FETCHING_STATUS);
       setStatus(FETCHED_STATUS);
   }, [url]);

   return {
       status,
   };
};
Enter fullscreen mode Exit fullscreen mode

The second test is a bit more tricky - React optimizes setting a sequence of states and therefore the test receives the “fetched” status instead of “fetching”. No async action is going on at the moment between those statuses, right?
We know that we’re going to use the “fetch” API so we can use that in order to create an async action which is eventually what we aim for, but there is nothing to handle this request when running the test - this is where MSW (Mock Service Worker) comes in.

I will bootstrap MSW for my test, making sure that when attempting to fetch the mock url it gets a response from my mocked server:

const mockUrl = 'https://api.instantwebtools.net/v1/passenger';
const mockResponse = {greeting: 'hello there'};
const server = setupServer(
   rest.get(mockUrl, (req, res, ctx) => {
       return res(ctx.json(mockResponse));
   })
);

describe('UseFetch hook', () => {
   beforeAll(() => server.listen());
   afterAll(() => server.close());
    ...
});
Enter fullscreen mode Exit fullscreen mode

And in my hook I will modify the code so it would make the request:

useEffect(() => {
       if (!url) return;

       const fetchUrl = async () => {
           setStatus(FETCHING_STATUS);

           const response = await fetch(url);
           const data = await response.json();

           setStatus(FETCHED_STATUS);
       };

       fetchUrl();
   }, [url]);
Enter fullscreen mode Exit fullscreen mode

But still when running the test, the last status is not available. Why?
The reason is that this is an async action and we need to allow our test to act accordingly. Put simply it means that it needs to wait for the hook to complete its next update cycle. Gladly there is an API just for that called waitForNextUpdate. I will integrate it in my test (notice the async on the “it” callback):

it('should first go into an "idle" status and then "fetching" and then "fetched" when initiated with a URL', async () => {
       const {result, waitForNextUpdate} = renderHook(() => useFetch({url: mockUrl}));
       await waitForNextUpdate();
       expect(result.all.length).toEqual(3);
       expect(result.all[0].status).toEqual(IDLE_STATUS);
       expect(result.all[1].status).toEqual(FETCHING_STATUS);
       expect(result.all[2].status).toEqual(FETCHED_STATUS);
   });
Enter fullscreen mode Exit fullscreen mode

Phew… that was hard, but hey, we have made good progress! My test passes and I know that when a url is given the hook goes through these 3 statuses: “idle”, “fetching” and “fetched”.

Can we check the data now? Sure we can :)
I will write a test to make sure that I’m getting the data which gets returned from my mock server:

it('should return the data from the server', async () => {
       const {result, waitForNextUpdate} = renderHook(() => useFetch({url: mockUrl}));
       await waitForNextUpdate();
       expect(result.current.data).toMatchSnapshot();
   });
Enter fullscreen mode Exit fullscreen mode

I’m using “toMatchSnapshot” here since it is more convenient for me to check the snapshot a single time for the JSON I expect to return and leave it as is. This is what Jest snapshots are best at (and not for checking component’s rendering). You can also compare it to the mockResponse defined earlier - whatever does it for you.

The test fails with ringing bells. Of course it does! I don’t set any data, update or return it in any way. Let's fix that:

const useFetch = ({url} = {}) => {
   const [status, setStatus] = useState(IDLE_STATUS);
   const [data, setData] = useState(null);

   useEffect(() => {
       if (!url) return;

       const fetchUrl = async () => {
           setStatus(FETCHING_STATUS);

           const response = await fetch(url);
           const data = await response.json();
           setData(data);

           setStatus(FETCHED_STATUS);
       };

       fetchUrl();
   }, [url]);

   return {
       status,
       data,
   };
};
Enter fullscreen mode Exit fullscreen mode

But since I added another update to the hook, a previous test which asserted that there will be only 3 update cycles fails now since there are 4 update cycles. Let’s fix that test:

it('should first go into an "idle" status and then "fetching" and then "fetched" when initiated with a URL', async () => {
       const {result, waitForNextUpdate} = renderHook(() => useFetch({url: mockUrl}));
       await waitForNextUpdate();
       expect(result.all.length).toEqual(4);
       expect(result.all[0].status).toEqual(IDLE_STATUS);
       expect(result.all[1].status).toEqual(FETCHING_STATUS);
       expect(result.all[3].status).toEqual(FETCHED_STATUS);
   });
Enter fullscreen mode Exit fullscreen mode

The 3rd cycle (result.all[2]) is the data setting. I won’t add it to this test though cause this test focuses on the status only, but you can if you insist ;)

Now that my Fetch hook is practically done let’s tend to some light refactoring -
We know that if we’re updating the state for both the status and data we can reach a situation where 1) the status and data do not align and 2) redundant renders. We can solve that with using the useReducer hook.
One slight change before we do - we know that now we’re removing a single update cycle (setting the data) since it will be bundled along with dispatching the “fetched” status, so we need to adjust one of our tests before we start:

it('should first go into an "idle" status and then "fetching" and then "fetched" when initiated with a URL', async () => {
       const {result, waitForNextUpdate} = renderHook(() => useFetch({url: mockUrl}));
       await waitForNextUpdate();
       expect(result.all.length).toEqual(3);
       expect(result.all[0].status).toEqual(IDLE_STATUS);
       expect(result.all[1].status).toEqual(FETCHING_STATUS);
       expect(result.all[2].status).toEqual(FETCHED_STATUS);
   });
Enter fullscreen mode Exit fullscreen mode

And our refactored code looks like this:

import {useEffect, useReducer} from 'react';

export const IDLE_STATUS = 'idle';
export const FETCHING_STATUS = 'fetching';
export const FETCHED_STATUS = 'fetched';
const FETCHING_ACTION = 'fetchingAction';
const FETCHED_ACTION = 'fetchedAction';
const IDLE_ACTION = 'idleAction';

const initialState = {
   status: IDLE_STATUS,
   data: null,
};

const useReducerHandler = (state, action) => {
   switch (action.type) {
       case FETCHING_ACTION:
           return {...initialState, status: FETCHING_STATUS};
       case FETCHED_ACTION:
           return {...initialState, status: FETCHED_STATUS, data: action.payload};
       case IDLE_ACTION:
           return {...initialState, status: IDLE_STATUS, data: null};
       default:
           return state;
   }
};

const useFetch = ({url} = {}) => {
   const [state, dispatch] = useReducer(useReducerHandler, initialState);

   useEffect(() => {
       if (!url) return;

       const fetchUrl = async () => {
           dispatch({type: FETCHING_ACTION});

           const response = await fetch(url);
           const data = await response.json();

           dispatch({type: FETCHED_ACTION, payload: data});
       };

       fetchUrl();
   }, [url]);

   return state;
};

export default useFetch;
Enter fullscreen mode Exit fullscreen mode

And here is our final test code:

import {renderHook} from '@testing-library/react-hooks';
import {rest} from 'msw';
import {setupServer} from 'msw/node';
import useFetch, {FETCHED_STATUS, FETCHING_STATUS, IDLE_STATUS} from '.';

const mockUrl = 'https://api.instantwebtools.net/v1/passenger';
const mockResponse = {greeting: 'hello there'};
const server = setupServer(
   rest.get(mockUrl, (req, res, ctx) => {
       return res(ctx.json(mockResponse));
   })
);

describe('UseFetch hook', () => {
   beforeAll(() => server.listen());
   afterAll(() => server.close());

   it('should exist', () => {
       const {result} = renderHook(() => useFetch());
       expect(result.current).toBeDefined();
   });

   it('should return an "idle" status when no url is given to it', () => {
       const {result} = renderHook(() => useFetch());
       expect(result.current.status).toEqual(IDLE_STATUS);
   });

   it('should first go into an "idle" status and then "fetching" and then "fetched" when initiated with a URL', async () => {
       const {result, waitForNextUpdate} = renderHook(() => useFetch({url: mockUrl}));
       await waitForNextUpdate();
       expect(result.all.length).toEqual(3);
       expect(result.all[0].status).toEqual(IDLE_STATUS);
       expect(result.all[1].status).toEqual(FETCHING_STATUS);
       expect(result.all[2].status).toEqual(FETCHED_STATUS);
   });

   it('should return the data from the server', async () => {
       const {result, waitForNextUpdate} = renderHook(() => useFetch({url: mockUrl}));
       await waitForNextUpdate();
       expect(result.current.data).toMatchSnapshot();
   });
});
Enter fullscreen mode Exit fullscreen mode

Noice :)

I know - There is still a lot that can be done to make this relatively simple implementation much better (exposing fetch errors, caching, etc.), but as I mentioned earlier, this is a good start to lay the foundation for creating a server interaction React Hook using TDD and MSW.

Care for a challenge? Implement a caching mechanism for this hook using the techniques discussed in this post đź’Ş

As always, if you have any ideas on how to make this better or any other technique, be sure to share with the rest of us!

Hey! If you liked what you've just read check out @mattibarzeev on Twitter 🍻

Photo by Philipp Lublasser on Unsplash

Top comments (5)

Collapse
 
sridhar_natuva profile image
sridhar.natuva •

This is good. This is pure tests on custom hook. Can you use that custom hook in any component and write a test case for the component.

I am trying to do that, i get undefined from the custom hook on the component.

Can you help me with this scenario.

Thanks.

Collapse
 
mbarzeev profile image
Matti Bar-Zeev •

Hi, can you please share some code (on github fir instance) so I can understand more what it is you're trying to do?

Collapse
 
sridhar_natuva profile image
sridhar.natuva •

Hi,
Here is the index page and i am getting data from a custom hook that is wrapped by useSWR hook.
Now i want to write tests for index page by mocking the custom hook.(mock service worker can help here ?)
stackblitz.com/edit/nextjs-gcee4q?...

Thread Thread
 
mbarzeev profile image
Matti Bar-Zeev •

Well, I think I understand where you struggle with it, so I took the opportunity to write a post about it here - dev.to/mbarzeev/mocking-data-fetch...
Hope this helps :)

Collapse
 
tmerlet profile image
tmerlet • • Edited

Nice example, thank you 🙏

result.all and waitForNextUpdate have been deprecated in renderHook, as it encourages testing implemenation details. see here. I'm curious how you would update this example knowing this... maybe TDD requires the testing of implementation details?

If you want to follow along, you'll need to update this test as follows (I'm sure there must be other ways but this is the best I found)

  it('should first go into an "idle" status and then "fetching" and then "fetched" when initiated with a URL', async () => {
    let all: { status: string }[] = [];

    const { result } = renderHook(() => {
      const value = useFetch({ url: mockUrl });
      all.push(value);
      return value;
    });

    await waitFor(() => expect(all.length).toEqual(3));
    expect(all[0].status).toEqual(IDLE_STATUS);
    expect(all[1].status).toEqual(FETCHING_STATUS);
    expect(all[2].status).toEqual(FETCHED_STATUS);
  });
Enter fullscreen mode Exit fullscreen mode

in addition I had trouble using the global fetch, which "I think" is not supported yet by msw (but should be part of node from V18 by default): github.com/mswjs/msw/issues/686#is...

So I imported 'node-fetch' and used that instead... I bootstrapped the project using create-react-app with the jest option, but node-fetch was throwing an error: "SyntaxError: Cannot use import statement outside a module". I googled around and the best way I found to solve this problem was by installing an earlier version of node-fetch npm install node-fetch@2 as well as the types if you are using typescript npm i --save-dev @types/node-fetch. @matti you might have a better way?

Thanks again đź‘Ź

Read next

sotergreco profile image

The Best Folder Structure for Your API

Sotiris Kourouklis -

ingeniouswebster profile image

The Battle of State Management: Redux vs Zustand

Pratik Singh -

repiki profile image

Ruby Array Methods That Will Blow Your Mind, Pt. 3: Lord of the Slices

Repiki -

chabbasaad profile image

Tools & Extensions for Vue JS

Chabba Saad -