Forem: Rufat Aliyev

Testing React Applications That Use Context Global State

Rufat Aliyev — Wed, 13 Jan 2021 04:22:21 +0000

Isn't satisfying to see all your test are passing with all those green tags in your terminal. I want to share the way I test my React applications that use Context to manage global state.

If you want to read how I use Context for global state management check out this post.

General guidelines

“Program to an interface, not an implementation.”
Design Patterns: Elements of Reusable Object Oriented Software

While my internship at Acerta we needed to set up our testing environment and I was assigned to research current testing approaches. As a result, I found two main streams in testing React applications.

Implementation oriented
Result oriented

Implementation oriented

If you are trying to test the internals of your component, like, is the state updating correctly, is the rendering happening, then you are doing implementation-oriented testing. The problem with this approach is that

your implementation could change while still rendering the same interface and functionalities. It means that every time you make changes to your component you will need to adjust your tests as well, which is not ideal.
you will need to have more tests and mocks.

Maybe you think that there are times that some logic needs to be thoroughly tested. In that case, your logic is too complex to be hosted by a React component. Create a custom hook and implement your logic there and import them to your component. This will make your component lighter and your testing easier.

Result oriented

Testing the result of your component is when you are testing your components closer to the way your users will interact with them. It means that you are not testing React rendered objects, but the real DOM. In this way, you will also test if your component is rendered at all, and if the elements that carry the main logic of the component are in the DOM, and if they behave correctly. The benefits of this approach is that

you will have more robust tests that will be subject to less often changes
you will test more with less code
you will test in a way as your application will be interacted by users

Mock API Requests

Enough of philosophy, let's get started with coding.

I usually use msw to mock my API requests. I strongly recommend it for your development environment. MSW is using service workers to intercept your API requests, which means that you don't change the way you fetch data. Just your API responses will come not from a server but predefined handlers.

It is very useful while doing testing. Because you can use it in the browser and node environment.

Mock Global State

Now that we are good with API requests, let's tackle the global state.

As my components are using the global state directly, I need to mock it so that I can assert if the methods provided by the global state are being called properly.

I start by mocking my store object and assign Jest mock functions to all the methods that will be imported by the components I will test.

export const store: DefaultContext = {
  getRandomRecipes: jest.fn(),
  getRecipeById: jest.fn(),
  searchByName: jest.fn(),
  searchByCountry: jest.fn(),
  searchByCategory: jest.fn(),
  searchByIngredients: jest.fn(),
  resetReviewState: jest.fn(),
  setRecipeList: jest.fn(),
  loading: false,
  recipeList: null,
  reviewBarOpen: false,
  reviewLoading: false,
  reviewedRecipe: null,
};

The next step will be creating a mock <StateProvider/>.

import React from "react";
import { Context } from "@/store/Context";
import { store } from "./mockStore";

export const StateProvider: React.FC = ({ children }) => {
  return <Context.Provider value={store}>{children}</Context.Provider>;
};

As you see here, I use the same Context element, but I pass my mock store to it as a value.

Alright, and now let's finally do some testing.

So the main technologies I use for testing are Jest and Testing-library.

Testing-library especially is created to encourage result-oriented testing. It provides you with utilities to render your component and deal with asynchronous methods in your components. It also provides screen API which represents the rendered element and selectors like getByText, getByTestId and etc.

I want to specially talk about getByTestId. You can get elements from DOM in numerous ways and most cases, it can be valid. But if you think about making your tests more resilient to changes you don't want them to be dependant on tag decisions someone made or alt text or text content, and so on. These are the things that can be changed more often and sometimes you can't do even anything about it. That's why I recommend using the data-testid property on your HTML tags.

One benefit is that no matter what you render as long as you have data-testid on it your test will pass.
Another advantage is that it will communicate to other developers that this particular element is linked to some tests.

Let's write some tests

I am going to test <ByCategory/> component from my Recippy project. This component is responsible for fetching categories from the server, displaying tabs with categories, and searching recipes by the selected category. It looks like this.

So I will mimic this in my test.

First, I start up my mock server. (msw)

describe("ByName", () => {
  server.listen();

Then I pick the method I want to run my assertion on. I use Jest spyOn method to reference the searchByCategorymethod in the global state.

  it("Should search by category", () => {
    const spy = jest.spyOn(mockStore, "searchByCategory");

Wrapping my element with my mock global state ...

    render(
        <StateProvider>
          <ByCategory />
        </StateProvider>
      );

Waiting for the loader to be unmounted. . .

    await waitForElementToBeRemoved(() => screen.getByTestId(LOADER));

Selecting a tab . . .

   const tab = screen.getByTestId(CATEGORY + index);

   expect(tab.textContent).toBe(categoryNames[index].strCategory);

   fireEvent.click(tab);

Submitting the search . . .

    const search_btn = screen.getByTestId(SEARCH_BTN);

    fireEvent.click(search_btn);

Asserting if my searchByCategory method is called properly . . .

   expect(spy).toBeCalledTimes(1);
  });

Finally, I close the server.

  server.close();
});

That's it. Nothing fancy.

As you can see, I do the same thing as the user would do, but I test lots of things there. I test if I got a result from API if my loader was there and disappeared after the request is finalized if I had tabs to click, and finally if I can call API again to get my search result.

As you can see this test covers most parts of the component. Of course, you can test use cases as well, but this is the case I am interested in.

Finally, remember that tests are dangerous if not implemented correctly.

You wanna know more about testing and Javascript development I would highly recommend following [Kent C. Dodds].

Thanks for reading.

Recipe App

Rufat Aliyev — Sun, 13 Dec 2020 01:53:06 +0000

What I built

I built a recipe app using NextJS and MaterialUI. The deployment was super smooth. Previously, I have used GCP and Heroku, honestly, the best deployment experience I have ever had was with DigitalOcean. No hustle at all. Good Job, guys!

Category Submission:

Random Roulette

App Link

https://recippy-3cm9c.ondigitalocean.app/

Screenshots

Description

You can search recipes by name, filter them by ingredients, countries, and categories.

Link to Source Code

https://github.com/rufataliy/Recippy

Permissive License

MIT

Background

I love cooking, so thought why not make an app that could be useful for me and others.

React Global State with useContext

Rufat Aliyev — Fri, 11 Dec 2020 22:21:30 +0000

Imagine your global state API looks like this.

const Index: React.FC = () => {
  const { loading, recipeList, getRandomRecipes} = useStore();
...

Just one hook that provides all you need from a global state handler. This could be achieved by using Context API natively provided by React 16.x.

According to the documentation, Context API is for avoiding prop drilling which means passing a prop down to deeply nested components through all its parents. You read more about his here.

We will leverage the concept of the hook of React to make the consuming process of context more developer-friendly.

First and simple, we need to create a context. I usually create all files that relate to the global state inside the store folder that is in the src folder of the project.

|__src
    |__components
    |__store
        |__Context.ts

The code for context will look like this.

export const Context = React.createContext(defaultContext)

You can omit defaultContex, but it is good practice to use it in order to be able to isolate and test it.

So, now we have created our context. Let move to the main part which is creating an actual global state. There is nothing fancy here just a simple custom hook with your states. I usually call it useGlobalState.

|__src
    |__components
    |__store
        |__Context.ts
        |__useGlobalState.ts

After creating the file we create the states that should be accessible from any component of our application and the methods to manipulate the state.

import { useState, useMemo } from "react";
import { makeApiRequest } from "../utils";

export const useGlobalState = () => {
  const [recipeList, setRecipeList] = useState(null);
  const [reviewBarOpen, setReviewBarOpen] = useState(false);
  const [loading, setLoading] = useState(true);

  const searchByName = useMemo(
    () => (keyword: string) => {
      makeApiRequest(
        `/api/search-by?keyword=${keyword}`,
        (data) => setRecipeList(data.meals),
        setLoading
      );
    },
    [setLoading]
  );

  const searchByIngredients = useMemo(
    () => (ingredients: string) => {
      makeApiRequest(
        `/api/filter-by?filterType=i&filterValue=${ingredients}`,
        (data) => setRecipeList(data.meals),
        setLoading
      );
    },
    [setLoading]
  );

  const openReviewBar = useMemo(() => () => 
                          setReviewBarOpen(true), [
                          setReviewBarOpen,
                        ]);

  const closeReviewBar = useMemo(() => () => 
                          setReviewBarOpen(false), [
                          setReviewBarOpen,
                        ]);
  const resetReviewState = useCallback(() => {
                            setReviewedRecipe(null);
                            closeReviewBar();
                           }, [closeReviewBar]);
  return {
    recipeList,
    searchByName,
    searchByIngredients,
    reviewBarOpen,
    resetReviewState,
  };
};

So, basically, what we are doing is exposing only those parts of the state and methods that should be accessible publically from child components.

The next step is optional but make this solution more elegant. I create an additional provider component.

|__src
    |__components
    |__store
        |__Context.ts
        |__useGlobalState.ts
        |__StateProvider.ts

import React from "react";
import { Context } from "./Context";
import { useGlobalState } from "./useGlobalState";

export const StateProvider: React.FC = ({ children }) => {
  const store = useGlobalState();

  return (
     <Context.Provider value={store}>
        {children}
     </Context.Provider>
  )
};

Next, I wrap my application to the StateProvider, If not I cannot access global in children components.

import React from "react";

export const App= ({children})=>{
 return (
    <StateProvider>
      <Layout>
        {children}
      </Layout>
    </StateProvider>
  );
};

Lastly, I implement a custom hook to consume the global state.

|__src
    |__components
    |__store
        |__Context.ts
        |__useGlobalState.ts
        |__useStateProvider.ts
        |__useStore.ts

import { useContext } from "react";
import { Context } from "./Context";

export const useStore = () => {
  const store = useContext(Context);
  return store;
};

That's it, our global state is ready to use. Now, you just need to call the hook and consume the provided API.

import React, { useEffect } from "react";
import { useStore } from "@/store";

export const ByName: React.FC = () => {
  const { searchByName, getRandomRecipes } = useStore();
  const [value, setValue] = useState("");

  useEffect(() => {
    if (!Boolean(value.trim())) {
      getRandomRecipes();
    }
  }, [value, getRandomRecipes]);

 ...

As a result, This keeps your components clean, only one place to look for bugs regarding your global state, and, also, isolates the data layer from the view layer which makes it easy to test this kind of application.

Testing

If you wonder how you would test your components that consume global state directly check out my other post where I walk you through process.
Let me know what's your implementation of the global state.

By the way, if you wanted to check the app where I implemented this style you can view it here and source code here.

Thanks for reading.