DEV Community: Serhat Genç

Unit testing in React

Serhat Genç — Wed, 14 Sep 2022 11:00:51 +0000

Introduction

Unit tests are tests we write cheaply and with little effort to ensure that components or functions are working as expected. Dividing the code into small pieces increases the maintainability and readability of the code. Such an approach will make it easier to write tests, especially in large-scale projects. We can also use unit testing for things like edge cases and testing APIs.

As for what happens if we don't write unit tests, it might not be a problem if our project is smaller scale. However, as the project grows and the business logic becomes more complex, you may find it difficult to track down bugs.

I created a small-scale weather application to help with this article. I will try to achieve 100% test coverage for this application.

First, let's take a look at how the application looks.

The general flow is as follows, we get the latitude and longitude of the user's location using the web API. I access the weather data with OpenWeatherMap and reflect it to the weather card component. The button on the lower left is for re-fetching the weather data. The button on the lower right allows us to expand the weather card and see extra information.

Setup and Mocking

Before continuing, I want to briefly show the final version of my API folder.

Keeping the APIs in different files will be useful in terms of order. For example, here I create weather-related APIs in api/weather.ts.

If we create a mock file with the same API file name in the API folder's __mocks__ folder, the mock function we created here will work in unit tests. This way, we will be running the tests without sending requests to the real API. But keep in mind that the function names need to be the same as well.

In cases where we want the API we use in the test to behave differently from the normal flow, we can do different implementations, such as throwing an error to the API, as you will learn later in the article, by using jest.spyOn. So the usage in jest.spyOn is no different from defining the mocked version of the APIs in the __mocks__ folder. It makes the most sense to define how they behave in the general flow to __mocks__ because only when I need to change the behavior of the API within a test, I can change it with jest.spyOn within the scope of that test.

As seen in the test script that comes ready with the create react app, we run our tests using react-scripts. By giving the file path of the API to Jest, we indicate that the relevant API is mocked. Since we have to specify this at the beginning of the tests, it makes more sense to put it in a file that is run before the tests. This file is setupTests and we need to create this file under the src file. In addition, if our application uses one of the web APIs, we can mock it here; otherwise, it will cause problems in our tests.

// src/setupTests.ts
jest.mock("api/weather");

Here I am telling Jest that the weather API will be mocked. Jest looks for this API file, and its functions in the __mocks__ folder.

React-script uses jest when running tests. Jest is a test runner that finds tests, runs the tests, and determines whether the tests passed or failed. Jest also uses a tool called Istanbul. This tool helps us get the test coverage report. Whereas react testing library provides virtual DOMs for testing React components.

The content of the weather card component rendered in App.tsx is populated with the request of the getWeatherData function. I defined getWeatherData as a mock function that returns fake data in the api/__mocks__/weather.ts file.

// api/__mocks__/weather.ts
import { mockedGetWeatherDataResponse } from "api/mockData/weather";

// mockedGetWeatherDataResponse is a suitable response that can be returned to this api function.

export const getWeatherData = async (
  params: Api.Weather.GetWeatherDataParams
) => Promise.resolve(mockedGetWeatherDataResponse);

Now that we have set the mock function, we can test the weather card component. Since App.tsx includes the weather card component, I will write the test in it.

Writing tests

import { render, screen, waitFor } from "@testing-library/react";
import { mockedGetWeatherDataResponse } from "api/mockData/weather";
import App from "App";

describe("App tests", () => {
  const setup = () => render(<App />);

  it("loads data successfully", async () => {
    setup();

    await waitFor(() => {
      expect(screen.getByTestId("city-name")).toHaveTextContent(
        mockedGetWeatherDataResponse.name
      );
    });
  });
});

Here, I wrote my tests in the describe block. This is not required, but you can use it if you want to group your related tests. We define the first parameter as the name of the block, and the second parameter as the callback containing our tests.

We write the tests in it or test blocks, just like in the describe block. The first parameter is the name of the test, and the second parameter is the callback to which the test will be written. If we have async actions in the code, it is useful to define this callback as async.

As mentioned above, we get the necessary dom elements from the react testing library. Here we assign the app component rendered to the virtual dom to a variable called setup. Calling the setup function at the beginning of the test will render the app component to the virtual dom.

As a first test, we will test whether the given data is rendered in the appropriate place. From the results returned from the mock data we defined, Izmir should appear as the city on the screen. There are many ways to find elements, such as by role, by text, or by test id. Searching with a test id is the easiest and most commonly used method. All you have to do is give the data-testid prop to the element you want to find.

We expect the text content of the element with this test id to be the same as the name in the mock data, which is İzmir. Here we must put the expect line in the waitFor as a callback because the data is accessed as a result of 2 async actions, which are getting the location and weather data.

npm run src/App.test.tsx

After coming to the terminal and running the test script with the path of the test file as above,

We are getting such an error. That is because I used a web API called navigator to find the user's location. To pass the test, the navigator needs to be mocked. We can handle the mocking process in the setupTests file.

// src/setupTests.ts
// When using getCurrentPosition in the flow, this is how the response is returned.
const mockGeolocation = {
  getCurrentPosition: (cb: any) => {
    return cb({
      coords: {
        latitude: 27.0881,
        longitude: 38.4942,
      },
    });
  }
};

global.navigator = Object.defineProperty(global.navigator, "geolocation", {
  value: mockGeolocation,
});

The getCurrentPosition function of the navigator's geolocation property is used in the flow. The structure where this function returns a suitable result is as above. When we run the test again, we will see that it passed.

Test coverage

Before we move on to the next test, I'll show you how to get the test coverage report to guide us on what to write the next test for. There is a script in package.json to run tests using react-scripts. Let's write a script here to get the test coverage report.

// package.json
//...
 "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "test:coverage": "react-scripts test --coverage --watchAll",
    "eject": "react-scripts eject"
  },
//...

To get coverage, we need to add the --coverage flag to the end of the test script.

If a file that reaches 100% test coverage does not appear in the coverage report, you can solve this problem by adding the --watchAll flag at the end of the coverage script. This flag watches files for changes and reruns all tests when something changes.

npm run test:coverage

After running the test coverage report script, you can see the report in the terminal.

If you want to look at the more readable, detailed, and eye-catching version, you may have noticed that a folder called coverage has been created inside your project. Open the Icov-report folder in the coverage folder and open the index.html in it with the live server. And you will see something like this.

As you can see, the WeatherCard component is 71.42% covered. Let's see which conditions are not covered.

The case where we extend the WeatherCard is not covered. This forms our next test case.

it("should expand the weather card", async () => {
    setup();

    userEvent.click(await screen.findByTestId("expand-card-button"));

    expect(await screen.findByTestId("text-humidity")).toHaveTextContent(
      mockedGetWeatherDataResponse.main.humidity.toString()
    );
  });

What we need to do here is a user action. The user needs to expand the card. You can use userEvent or fireEvent for such user actions. But keep in mind that userEvent can better reflect the actual behavior of the user.

After expanding the card, the humidity level should appear on the screen. I expect this value to be on the screen and equal to the value in the mock data.

Due to the UI library I use here, I get an error that window.scrollTo is not implemented when running the test, but the test passes successfully. If we mock this in setupTests, we will not receive such a warning.

window.scrollTo = jest.fn();

This is how I mocked the window.scrollTo in setupTests file.

Moving on to the next test, the catch part of the function from which we pull the weather is not covered. Here we need to drop the weather function into the catch state.

it("should throw error while fetching weather data", async () => {
    jest.spyOn(weather, "getWeatherData").mockImplementation(() => {
      throw new Error();
    });

    setup();

    await waitFor(async () => {
      expect(weather.getWeatherData).toThrowError();
    });
  });

Here, before the test starts, we set the getWeatherData function of the weather API to throw an error. We use Jest's spyOn function for this. The first parameter is the weather, which is the structure containing the weather-related functions, and the second parameter is the name of the function as a string. Then we make a mock implementation and throw an error.

Everything in the src folder is 100% tested. However, there is no point in testing the src/index.tsx file, so we can exclude it from the test coverage. Let's add this to the package.json and which file extensions to test.

// package.json
//...
"jest": {
    "collectCoverageFrom": [
      "src/**/*.{ts,tsx}",
      "!src/index.tsx"
    ]
  }
//...

All that's left is to test the API folder. I will create the API tests in the tests folder under the API folder. I created a test file named weather.test.tsx in it.

import { weather } from "api";
import { mockedGetWeatherDataResponse } from "api/mockData/weather";
import axios from "axios";
import MockAdapter from "axios-mock-adapter";

const mock = new MockAdapter(axios);
jest.unmock("api/weather");

describe("Weather api tests", () => {
  it("requests and gets a successful response from getWeatherData", async () => {
    const url = "https://api.openweathermap.org/data/2.5/weather";
    const params: Api.Weather.GetWeatherDataParams = {
      lat: 100,
      lon: 200,
    };

    mock.onGet(url).reply(200, mockedGetWeatherDataResponse);

    const response = await weather.getWeatherData(params);

    expect(response).toEqual(mockedGetWeatherDataResponse);
  });
});

Since there is no business-related code in the API function, we will only test the request. We will use axios-mock-adapter for this. And we don't want the requests to go to their counterparts in the __mocks__ folder as before. For this, we remove the mocking process we performed in setupTests here with jest.unmock.

MockAdapter needs the instance you use while making HTTP requests as a parameter. Since I make HTTP requests using Axios, I pass the Axios instance to the MockAdapter. I pass the URL to mock.onGet as a parameter, then the reply to this URL should be equal to the mock data we defined earlier and 200 status code. Then we request the relevant API and expect the return result to be the same as the mock data.

There you have it, 100% test coverage 🎉.

In a real-life business project, 100% test coverage is not an unattainable percentage, but a percentage that will take time to reach. In reality, the workflow may not be this simple, and things will get complicated. For this, it is best to start by choosing a percentage like 50% as a target, and it will be possible to reach 100% over time.

Github repository if you want to take a look at the final version of the project.

Creating a reusable table component with React-Table and Material UI

Serhat Genç — Sat, 06 Aug 2022 07:42:38 +0000

Introduction

Tables are tools that we often use in our personal and business projects. A table is a structured dataset consisting of rows and columns. It allows us to easily read, filter, and search large-scale data.

I will show you how we can create a reusable table component using Tanstack's react-table and Material UI, and why we should use react-query where big data is used, such as tables.

The framework I will use is Next.js, but you can follow this article using any react framework of your choice.

First, let's start by installing the necessary packages for our project.



npm install @tanstack/react-table @tanstack/react-query @mui/material @emotion/react @emotion/styled

In terms of being type-safe, I will use Typescript, and for my HTTP requests, I will use Axios. These two packages are not essential to install.

Creating the table

We will create a table index file in the components folder. This is where we will structure our table. The table accepts two props named data and columns. To separate the data into the correct columns, the objects of the column array must contain a property named accessorKey. This key must be the same as the property key of the related data of the objects in the data array.

For example, if there is email information in our data and this email information is sent with the email property key, this means that the accessorKey of our column will be email. An example of usage is shown in the following steps.

To map data and columns to the table, we get our mapping functions from the useReactTable hook provided by react-table. We mapped data and column elements between Material UI table components. It's easy to customize the styles of these pre-styled table components for yourself.

The table component should look like this.



// components/Table/index.tsx
import {
  Paper,
  Table as MuiTable,
  TableBody,
  TableCell,
  TableHead,
  TableRow,
} from "@mui/material";
import {
  ColumnDef,
  flexRender,
  getCoreRowModel,
  useReactTable,
} from "@tanstack/react-table";
import { FC } from "react";

interface TableProps {
  data: any[];
  columns: ColumnDef<any>[];
}

export const Table: FC<TableProps> = ({ data, columns }) => {
  const { getHeaderGroups, getRowModel } = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
  });

  return (
    <Paper elevation={2} style={{ padding: "1rem 0px" }}>
      <MuiTable>
        <TableHead>
          {getHeaderGroups().map((headerGroup) => (
            <TableRow key={headerGroup.id}>
              {headerGroup.headers.map((header) => (
                <TableCell key={header.id}>
                  {header.isPlaceholder
                    ? null
                    : flexRender(
                        header.column.columnDef.header,
                        header.getContext()
                      )}
                </TableCell>
              ))}
            </TableRow>
          ))}
        </TableHead>
        <TableBody>
          {getRowModel().rows.map((row) => (
            <TableRow key={row.id}>
              {row.getVisibleCells().map((cell) => (
                <TableCell key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </TableCell>
              ))}
            </TableRow>
          ))}
        </TableBody>
      </MuiTable>
    </Paper>
  );
};

Usage

Now let's use the table in the project to test it and then try to improve the table. I will be getting the data from an API provided by Gorest. After we got the data, we sent it to the table as a prop.

It is time to create the column array. As I said above, accessorKey is required, and the header property is what will be on that column's header. Header property is optional, and when you do not provide this property, the value here will take the string value you wrote to the accessorKey. If you want to change what is on the header, you can provide a string or JSX callback.

The cell is another useful property. We can provide a callback here to give a custom look to our data cells for the column we want. The callback we returned on the cell property is giving us lots of information and functionality with a parameter. By digging around that parameter, you can find lots of details about your table, rows, and columns.



//pages/columns.ts
import { Chip } from "@mui/material";
import { ColumnDef } from "@tanstack/react-table";

export const columns: ColumnDef<any, any>[] = [
  {
    accessorKey: "name",
    header: "Name",
  },
  {
    accessorKey: "email",
    header: "Email",
  },
  {
    accessorKey: "gender",
    header: "Gender",
  },
  {
    accessorKey: "status",
    header: "Status",
    cell: (row: any) => {
      return (
        <Chip
          label={row.getValue()}
          size="small"
          color={row.getValue() === "active" ? "primary" : "default"}
        />
      );
    },
  },
];

Now let's give the column array to the table as a prop and see the final version of the table usage.



//pages/index.tsx
import { useEffect, useState } from "react";
import type { NextPage } from "next";
import axios from "axios";
import { Box } from "@mui/material";
import Table from "../components/Table";
import { columns } from "./columns";

const Home: NextPage = () => {
  const [users, setUsers] = useState<Api.Users.Data[] | undefined>(undefined);

  const fetchUsers = async () => {
    const { data } = await axios.get<Api.Users.FetchUsersResponse>(
      "/api/users"
    );

    setUsers(data.data);
  };

  useEffect(() => {
    fetchUsers();
  }, []);

  return (
    <Box padding={6}>{users && <Table data={users} columns={columns} />}</Box>
  );
};

Table

Improving the table

To improve the table, we are going to add;

Pagination
Search field
Skeleton loading
Click row action
Custom header component
Memoization
React query for HTTP requests

Pagination

This is the server-side pagination implementation. The table will now take two new props named page and pageCount.

If we have information about the page count, react-table wants us to give the page count to the useReactTable hook. If we don't have the page count information, we can pass -1. We also need to set the manuelPagination property to true to handle the pagination manually.



const { getHeaderGroups, getRowModel } = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
    manualPagination: true,
    pageCount,
  })

The page prop is for exposing the current page value to the outside of the table as a callback function. Invoke this function on the pagination change function with the current page value. This will come in handy as we want to keep track of the current page value outside of the table.

We are going to keep the current page value inside the table component as a state.

Instead of using the nextPage or previousPage functions provided to us by useReactTable, Material UI has a pagination component that will do an excellent job of paginating the table. This component handles pagination functions under the hood, so it only needs a few props to work.

The pagination functions in useReactTable are mostly used for client-side pagination.

The pagination component takes these three props named; count, page, and onChange. Count is the total number of pages, page is the current page and onChange is a callback that fires when the state changes.



const handlePageChange = (
  event: ChangeEvent<unknown>,
  currentPage: number
) => {
  setPaginationPage(currentPage === 0 ? 1 : currentPage);
  page?.(currentPage === 0 ? 1 : currentPage);
};

{pageCount && page && (
  <Pagination
    count={pageCount}
    page={paginationPage}
    onChange={handlePageChange}
    color="primary"
  />
)}

Search field

We will retrieve the table results based on what we type in the search field. On the handleSearchChange function, we invoke the search callback given to the table to return the typed value. Notice that wrapping around the handle function with a debounce function is crucial because we don't want to return every typed value. This can cause problems such as making requests to an API on every typed value.




const handleSearchChange = (
    e: ChangeEvent<HTMLInputElement | HTMLTextAreaElement>
) => {
    search && search(e.target.value);
};

{search && (
  <TextField
    onChange={debounce(handleSearchChange, 1000)}
    size="small"
    label={searchLabel}
    margin="normal"
    variant="standard"
  />
)}

Skeleton loading

The table will display skeleton loading depending on the isFetching prop. The skeleton count on the table defaults to 10, and it can be overridden by giving the skeletonCount prop. We can think of the skeleton count prop as a row count for the skeletons, but we need the column count as well to render it on the table properly. We can get the number of columns with the getAllColumns function provided by useReactTable. The table includes the option of a skeleton height prop as well.



const { getHeaderGroups, getRowModel, getAllColumns } = useReactTable({
  data,
  columns,
  getCoreRowModel: getCoreRowModel(),
  manualPagination: true,
  pageCount,
});

const skeletons = Array.from({ length: skeletonCount }, (x, i) => i);

const columnCount = getAllColumns().length;

{
  !isFetching ? (
    getRowModel().rows.map((row) => (
      <StyledTableRow key={row.id}>
        {row.getVisibleCells().map((cell) => (
          <TableCell key={cell.id}>
            {flexRender(cell.column.columnDef.cell, cell.getContext())}
          </TableCell>
        ))}
      </StyledTableRow>
    ))
  ) : (
    <>
      //the mapping part of the skeletons
      {skeletons.map((skeleton) => (
        <TableRow key={}>
          {Array.from({ length: columnCount }, (x, i) => i).map((elm) => (
            <TableCell key={elm}>
              <Skeleton height={skeletonHeight} />
            </TableCell>
          ))}
        </TableRow>
      ))}
    </>
  );
}

Click row action

When we map the data to the table using the getRowModel function, we can get details about that row or cell. Just pass the onClickRow prop function with row and cell parameters to the onClick property of the cell.



getRowModel().rows.map((row) => (
  <StyledTableRow key={row.id}>
    {row.getVisibleCells().map((cell) => (
      <TableCell
        onClick={() => onClickRow?.(cell, row)}
        key={cell.id}
      >
        {flexRender(cell.column.columnDef.cell, cell.getContext())}
      </TableCell>
    ))}
  </StyledTableRow>
))

Custom header component

This is in case of a need for a header component for the table. We can place it above the search field.



<Box paddingX="1rem">
  {headerComponent && <Box>{headerComponent}</Box>}
  {search && (
    <TextField
      onChange={debounce(handleSearchChange, 1000)}
      size="small"
      label={searchLabel}
      margin="normal"
      variant="standard"
    />
  )}
</Box>

Memoization

We need to apply memoization to prevent possible re-renders or computationally expensive performance losses.

We are going to wrap the data, column, and headerComponent props into useMemo to prevent expensive re-calculation.



const memoizedData = useMemo(() => data, [data]);
const memoizedColumns = useMemo(() => columns, [columns]);
const memoisedHeaderComponent = useMemo(
  () => headerComponent,
  [headerComponent]
);

Wrapping the table export with memo to prevent unnecessary re-renders. This way, the component only re-renders when the props are changed.



//...

const Table: FC<TableProps> = ({
  //...
}) => {
  //...

  return (
    //...
    )
};

export default memo(Table);

React query

React-query is a fetching tool by Tanstack. React-query will cache the HTTP requests we make. Most of the time, the size of the data we will use in the table is considerably large, so we can prevent the delay in loading the data in the table by caching HTTP requests. You can see that after implementing the react-query, the HTTP requests you make are returned with a 304 code. This shows that the data is being read from the cache, or you can make a more detailed observation by installing @tanstack/react-query-devtools, one of the developer tools for react-query. Note that this tool is only available on the development build of the project.

The useQuery hook provides the cached data, the status of our request, and the error object for possible errors. The usage is simple; for the first parameter, provide a key or array of keys; for the second parameter, the fetcher function for your data; and for the third parameter, the options object for the react-query, which is optional. Any change to the keys will trigger the fetcher function, so it makes sense that we provide this key value with our current page or search value.

Since I don't want it to refetch every time I switch windows on the browser, I set the options object's refetchOnWindowFocus property to false. Let's set the keepPreviousData property to true for a smooth transition between the pages in the table.



const [currentPage, setCurrentPage] = useState<number | undefined>(1);
const [search, setSearch] = useState<string | undefined>("");

const { data, isFetching, isError, error, isSuccess } = useQuery<
    Api.Users.FetchUsersResponse,
    Error
  >(["users", currentPage, search], fetchUsers, {
    refetchOnWindowFocus: false,
    keepPreviousData: true,
  });

Final version of the table

This was the end of my article. I hope this article helped you to build your reusable table.

If you want to take a look at the full code, here is the Github Repository

or CodeSandbox preview

codesandbox.io