DEV Community: Bonnie Schulkin

Why are functional tests so much longer than unit tests?

Bonnie Schulkin — Thu, 02 Jun 2022 23:13:53 +0000

My unit testing background has trained me to write short tests, each covering one discrete piece of code. This makes unit tests simple to read and easy to diagnose. So why can’t this approach be applied to functional tests?

Functional Tests vs Unit tests

Let’s back up a bit here to distinguish between unit and functional tests. Unit tests isolate one piece of code, often a function or React component. By definition, they are tightly associated with the code, which makes them easy to diagnose (they point right to the area in the code that’s causing the failure!) but sometimes farther away from the actual user experience (especially if the coder uses mocks to keep other parts of code from polluting the unit test).

Functional tests on the other hand, test a user flow representing some functionality of your app. These emphasize interacting with the app the way a user would (clicking buttons and entering text) and de-emphasize any focus on specific code (you may have heard that it’s better not to test “internals” — or what’s going on in the code — because this makes your tests brittle and susceptible to breaking on refactors, even though there’s nothing wrong with your app).

React testing is currently trending strongly toward functional tests and away from isolated unit tests. This is great for the reasons mentioned above and in my Enzyme vs Testing Library post, but it can lead to tests that seem uncomfortably long and meandering to an old unit tester like me.

Example of a long(ish) functional test

Say you have an app that allows people to design and order an ice cream sundae. Before they submit the order, the terms and conditions warn their ice cream order isn’t ever gonna happen (via a popover):

You can’t say you weren’t warned

The test

Here is the test for the popover, using React Testing Library syntax. This test is short compared to a lot of my actual functional tests (hence the “ish” in the title of this section). Still I wanted something small and easy to follow for this article.

    test('popover responds to hover', async () => {  
          render(<SummaryForm />);  

          // assertion 1:   
          // popover starts out hidden  
          const nullPopover = screen.queryByText(  
            /no ice cream will actually be delivered/i  
          );  
          expect(nullPopover).not.toBeInTheDocument();  

          // assertion 2:   
          // popover appears upon mouseover of checkbox label  
          const termsAndConditions = screen.getByText(/terms and conditions/i);  
          userEvent.hover(termsAndConditions);  

          const popover = screen.getByText(/no ice cream will actually be delivered/i);  
          expect(popover).toBeInTheDocument();  

          // assertion 3:  
          // popover disappears when we mouse out  
          userEvent.unhover(termsAndConditions);  
          await waitForElementToBeRemoved(() =>  
            screen.queryByText(/no ice cream will actually be delivered/i)  
          );  
        });

This test has three assertions:

The popover is hidden when the component is first rendered
The popover appears when the mouse hovers over “Terms and Conditions”
The popover disappears when the mouse leaves “Terms and Conditions”

Why not make three separate tests?

This particular test could be broken into three tests, one for each of the assertions above:

    // test #1 //
    test('popover starts out hidden', async () => {  
      render(<SummaryForm />);
     // assertion 1  
      const nullPopover = screen.queryByText(  
        /no ice cream will actually be delivered/i  
      );  
      expect(nullPopover).not.toBeInTheDocument();  
    });

    // test #2 //
    test('popover appears after mouseover', () => {  
      render(<SummaryForm />);  

      // find and mouseover the Terms and Conditions text  
      const termsAndConditions = screen.getByText(/terms and conditions/i);  
      userEvent.hover(termsAndConditions);
     // assertion 2  
      popover = screen.getByText(/no ice cream will actually be delivered/i);  
      expect(popover).toBeInTheDocument();  
    });

    // test #3 //
    test('popover disappears on mouseout', () => {  
      render(<SummaryForm />);  

      // find and mouseover the Terms and Conditions text  
      const termsAndConditions = screen.getByText(/terms and conditions/i);  
      userEvent.hover(termsAndConditions);  

      // make sure the assertion appeared  
      popover = screen.getByText(/no ice cream will actually be delivered/i);  
      expect(popover).toBeInTheDocument();
     // assertion 3  
      userEvent.unhover(termsAndConditions);  
      await waitForElementToBeRemoved(() =>  
        screen.queryByText(/no ice cream will actually be delivered/i)  
      );  
    });

However, this is not necessarily an improvement — especially when it comes to separating tests (2) and (3). In order to set up the third test (popover disappears), we’d have to go through all the same steps we went through in the second test (getting the popover to appear, since we don’t know whether the popover disappeared unless it was actually there at some point).

Repeating the “appears” code in two separate tests feels repetitive and unnecessary.

What about a beforeEach?

Maybe we should put the “appears” code in a beforeEach that runs, well, before each test.

    describe('popover appears and disappears', () => {  
      beforeEach(() => {  
        render(<SummaryForm />);  

        // find and mouseover the Terms and Conditions text  
        const termsAndConditions = screen.getByText(/terms and conditions/i);  
        userEvent.hover(termsAndConditions);  
      });

    // test #1 //
    test('popover starts out hidden', async () => {  
      render(<SummaryForm />);
     // assertion 1:   
      const nullPopover = screen.queryByText(  
        /no ice cream will actually be delivered/i  
      );  
      expect(nullPopover).not.toBeInTheDocument();  
    });

    // test #2 //
    test('popover appears after mouseover', () => {  
       // assertion 2:   
       popover = screen.getByText(/no ice cream will actually be delivered/i);  
       expect(popover).toBeInTheDocument();  
     });

    // test #3 //
    test('popover disappears on mouseout', () => {  
       // assertion 3  
       userEvent.unhover(termsAndConditions);  
       await waitForElementToBeRemoved(() =>  
         screen.queryByText(/no ice cream will actually be delivered/i)  
       );  
     });  
   });

Here, we’re writing one test that doesn’t do anything other than assert the popover is in the document. Then there's a second test that builds on the beforeEach by running through the "disappears" code. That would work to break this particular test into three tests.

Reasons NOT to use a beforeEach

Any time you break up the test code by using beforeEach, the code is less readable and requires more effort to determine what exactly happened when debugging failing tests.
This second reason is the stronger one for me.

For this fairly simple user flow test, one beforeEach would cover the setup for both of the tests that aren't for initial conditions. However, imagine a more involved user flow, where a user:

logs on to the site
selects some ice cream scoops and toppings
sees the order summary
agrees to the terms and conditions
sees a confirmation page

A single beforeEach will not be able to cover the setup for the half dozen or so actions we go through as part of the flow. If we wanted to isolate each action / assertion into its own test, it would require either

a. repeating a lot of the setup of the previous tests, or

b. mocking and/or setting the context value explicitly in order to set up the tests -- which is frowned upon in this type of functional, user-based testing because it's not what a user would actually do to get into that situation.

Conclusion

The above is a verbose way of saying: most functional tests go through a series of steps, each step relying on the consequences of the previous step. The only way to run these tests without a huge amount of complexity or verbosity is to go through the whole flow in a single test, asserting along the way.

Is this isolated? No. Is this testing one specific area of the code? Also no. The point here is to test the app, not the code so that the tests more accurately reflect whether or not the app is working from a user’s perspective. The down side is that these tests are harder to debug since they’re more vague about which part of the code caused the error. This is part of the cost of functional testing. If you’re interested in how unit testing can mitigate this, take a look at my article on When to Unit Test your React App.

When to unit-test your React app

Bonnie Schulkin — Thu, 02 Jun 2022 23:03:49 +0000

Image by Bernd Hildebrandt from Pixabay

React testing is trending toward functional testing: test your app the way a user would use it. The tests go through user flows, and are decoupled from the code (testing behavior over implementation). This is fantastic when it comes time to refactor your code, or update the code without changing the behavior. Since the tests are tied only to the behavior, there’s no need to update the tests. Champagne all around! 🍾

This leaves a question, though: is there any space left in React for unit testing (tests that isolate one unit of code, often a function or component)?

Unit tests can be functional tests

Functional testing and unit testing aren’t mutually exclusive. Functional testing means testing a certain flow of your app, which could be contained in a single component.

For example, say you have a component, Quote, that displays a pithy quote and links to the author’s website. Some authors might not have a web site, though (Abraham Lincoln was notoriously bad at keeping up with web technology). Your tests need to check that the quote renders correctly for both situations: authors who have a link, and those who don’t.

When will Abe get a web presence?

These are functional tests for a user experience: they confirm the author’s name is either a link to the right destination, or plain text without a link for author data without a web site link. But they’re also unit tests for the Quote component. The test can render the Quote component with the quote and author data as props, and the tests are isolated to that one component. So here you’re writing unit tests simply because all the code for your functional test is contained within one unit.

Okay, so this example seems to be “unit testing as a technicality.” You’re actually doing functional tests that just happen to be unit tests. Are there any reasons you might want to unit test deliberately? Read on, my friends.

Unit tests help diagnose other failing tests

Functional testing is awesome when it comes to refactors (see comments about champagne above). But, when you test behavior and not implementation, your tests are intentionally decoupled from your code — which makes it harder to diagnose failing tests.

In a large, complicated project, there could be dozens or hundreds of lines of code responsible for a certain functional test, and narrowing down the cause of a failure could take a fair amount of time and effort. In some cases, you could potentially spend more time tracking down test failures than you would maintaining unit tests.

If there is a likely potential point of failure for one or more functional tests, you might consider making a unit test to cover it. This way, you can easily zero in on what is causing the functional test to fail — or eliminate a potential reason the functional test is failing.

As a simple example, imagine an app where someone can look up laws about backyard chicken coops for a particular city. The user selects a state from a drop-down menu, which populates a second drop-down menu with cities in that state that have such laws. Some states (I’m looking at you, California) have a lot of cities, so the city menu is broken into sub-menus by alphabet if there are more than 20 cities in the state.

oof, Califorina

You may write a functional test where a user navigates to the search page, selects a state and a city, and sees the correct legal information. The most complicated part of this test — and most likely point of failure — is the appearance and content of the second drop-down containing the city options.

So here you might want to write unit tests to support your functional test. These tests could render only the form element and ensure that the second menu is not there when you load the page, that it contains the correct data for a state with 20 or fewer cities that have ordinances, and that the menu paginates properly for cities that have more than 20 cities.

This type of unit test makes it easier to diagnose failing functional tests. If all of these unit tests pass and your functional test fails, you know that the problem lies elsewhere. But if you find a failing unit test, you know what you have to fix in order to get the functional test to pass.

Unit tests confirm data sent to the server

Your functional React tests generally don’t involve your server. It’s common to use a tool like Mock Service Worker to simulate responses from the server, but how do you know that your app is sending the correct data to the server?

For example, say you have a Redux action creator that processes form data and creates a JSON patch to update an entity on the server. You may want to write unit tests for this action creator to make sure that the JSON patch includes all the necessary data (and none of the extraneous data) for particular sets of form inputs.

This is testing implementation to be sure! The user neither knows nor cares about the exact data being passed to the server. However, functional tests usually don’t involve the actual server; that’s reserved for end-to-end tests. So this type of unit test will highlight where an end-to-end test is (or isn’t!) breaking down — or even better, prevent you from pushing code that breaks end-to-end tests in the first place.

Unit tests for edge cases that don’t affect render

It doesn’t always make sense to render the whole app (or even a particular component) to cover all the edge cases for a helper function.

spoiler alert: the secret word is “party”

Imagine you have a word game app that needs to check how many letters a guess has in common with the “secret word.” You write a helper function for this, which can easily be unit-tested to make sure it does the right thing when (a) the guess has more than one of the same letter, (b) the secret word has more than one of the same letter, (c ) the word has all the same letters as the secret word, (d) the words have zero letters in common.

The app does the same thing with the match count regardless of the above conditions, so it’s not necessary to render your JSX to test edge cases for this particular function. You will want to test this logic to make sure any added code doesn’t introduce errors, though. So here, unit tests of this function are the best way to go.

Summary

I have switched mostly to functional tests along with the prevailing best practices. However, I still use unit tests when:

my functional tests happen to test only one unit
there’s a likely point of failure in a longer functional test
I want to confirm that the correct data is sent to the server
I’m testing edge cases for a helper function that don’t affect rendering

Testing React Apps that use React Router

Bonnie Schulkin — Thu, 02 Jun 2022 22:52:22 +0000

Note: This post is about React Router 5, not React Router 6

So your React app, like a lot of modern apps, uses React Router to get users from one page to another. And you, like any thorough tester, want to account for React Router in your testing. This post will help you learn about the syntax to get you started testing React Router with your app.

Our App

Note: you can find the code for this project on GitHub. It will not win any awards for design. 😝

For the purposes of this post, we’ll imagine a restaurant website that looks like this:



import { Switch, Route, Link } from "react-router-dom";
import Home from "./Home";
import Menus from "./Menus";
import Locations from "./Locations";
import About from "./About";export default function App() {
  return (
    <div>
      <nav>
        <Link to="/">Our Restaurant</Link>
        <Link to="/menus">Menus</Link>
        <Link to="/locations">Locations</Link>
        <Link to="/about">About</Link>
      </nav>
      {/* routing */}
      <Switch>
        <Route path="/menus" component={Menus} />
        <Route path="/locations/:id" component={Locations} />             
        <Route path="/locations" component={Locations} />
        <Route path="/about" component={About} />
        <Route path="/" component={Home} />
      </Switch>
    </div>
  );
}

Note that the Router is not included in the App component. I’ve included it in src/index.js instead. By omitting it from the App component, we are able to use a test router in our tests which is more easily manipulated.

What if using a test router feels too artificial?

If you have qualms about using a different Router in your tests vs. production, you’ll probably want to to:

Include the Router in your App component;
Always render the App component in your tests (never child components like Locations);
Navigate to your pages in tests by finding and clicking links on the page

The positives of this approach: you don’t need to read the rest of this post 🙃 (and your test setup will be less complicated). The negatives: you can’t immediately load a routing history (the current page and previous pages) in test setup; you need to go through all the user interactions to build the history.

The Locations Component

If you’re still here, then you’re interested in learning about using a different router in your tests. In this post, we’ll focus on the general locations page with no URL parameter:



    <Route path="/locations" component={Locations} />

And the specific page for a particular location id:



    <Route path="/locations/:id" component={Locations} />

The Locations component uses useParams to get the :id URL param. If the id param is falsy, that means the route was /locations with no param, and, the component displays a list of location links:

If the id param is truthy, then it will display information for that particular location:

Example code for the Locations component



import { useParams, Link } from "react-router-dom";

export default function Locations() {
// We can use the `useParams` hook here to access
// the dynamic pieces of the URL.
const { id } = useParams();// in a real app, this info would come from the server

const locationData = {
  "san-francisco": {
    name: "San Francisco",
    address: "123 Main Street",
  },
  berkeley: {
    name: "Berkeley",
    address: "456 First Street",
  },
  oakland: {
    name: "Oakland",
    address: "789 Elm Street",
  },
};// no id? then just list links for all the locations
  if (!id) {
    return (
      <div>
       <h1>Locations</h1>
         <ul>
         {Object.entries(locationData).map(([id, data]) => {
            return (
            <li key={id}>
              <Link to={`/locations/${id}`}>{data.name}</Link>
            </li>
          );
        })}
        </ul>
      </div>
    );
  }// if there's an id URL parameter, give information about this location
  const data = locationData[id];
  return (
    <div>
      <h1>Location: {data.name}</h1>
      <p>{data.address}</p>
    </div>
  );
}

Including Router Context when Testing

Note: We will use* Jest as a test runner and Testing Library for rendering React components in this blog post.

Let’s make a simple test for our Locations component in Locations.test.js. No big deal, just seeing that it renders without error:



import { render } from "@testing-library/react";
import Locations from "./Locations";

test("renders without error", () => {
  render(<Locations />);
});

Uh oh

When we run this test with Jest, we get this ugliness:

The problem is, we’re trying to use useParams outside of a Router provider. No wonder Jest is confused.

The Solution

As luck would have it, Testing Library makes it easy to adapt its render function to wrap with whatever your UI elements might need — be it the React Router provider, or any other type of provider (see “Including the Router and other Providers” below for rendering with multiple providers).

The Testing Library React docs describe how to create a custom render that includes a wrapper. In our case, we could create this test-utils.jsx file in our src directory:



import { render } from "@testing-library/react";
import { MemoryRouter } from "react-router-dom";

// create a customRender that wraps the UI in a memory Router
const customRender = (ui, options) => {
  return render(ui, { wrapper: MemoryRouter, ...options });
}

// re-export everything
export * from "@testing-library/react";

// override render method
export { customRender as render };

Now, if we import render (and screen, and any other Testing Library imports) from this file instead of from @testing-library/react all of our rendered components will be wrapped in a MemoryRouter before being rendered.

Note: The React Router docs recommend *MemoryRouter* for testing; you can see other options in the React Router testing docs).

For the new and improved Locations.test.js, simply change the first line to import from the test-utils module:



    import { render } from "./test-utils";

Re-run the tests, and voila!

aaah, much better

Testing Location URL params

Ok, so the component renders without error. That’s one test, but I want to know that it renders the right thing without error. How can I specify what the route is?

We’ll need to update our render in test-utils.jsx to accept an initial route, which we can feed to the MemoryRouter. The “Memory” part means it stores routes in memory, as opposed to using a browser.

Note: In this case, we only need one initial route; in other cases, you might want to pass a whole array of historical routes (for example, if you were testing authentication that returned the user to the referring route).*

Using a function for the render wrapper

When we didn’t care about specifying initial routes, it was fine to specify the render wrapper as the MemoryRouter function in test-utils.jsx:



    render(ui, { wrapper: MemoryRouter, ...options });

However, now we want to add a prop to MemoryRouter, and things are going to get more interesting. The prop we want to add is initialEntries , as recommended in the “Starting at Specific Routes” docs for React Router Testing.

Because of that prop, we are going to have to make a new function for the wrapper value. The wrapper value has always been a function (MemoryRouter is simply a functional component after all), but now we need to dig in and get our hands a little dirty.

The function for wrapper takes, among other props, children. The Testing Library React setup docs for Custom Render show how to use the children prop in a wrapper function arg. This code does the same thing our previous code:



const MemoryRouterWithInitialRoutes = ({ children }) =>
  <MemoryRouter>{children}</MemoryRouter>;

const customRender = (ui, options) => {
  return render(
    ui,
    {
      wrapper: MemoryRouterWithInitialRoutes,
      ...options
    }
  );
}

But now we have some more room to maneuver.

Passing initial entries to the wrapper function

We want to be able to pass the initial entries to the options for the render function, something like:



    render(<App />, { initialRoutes: ["/locations/berkeley"] });

Then we need to get this to the MemoryRouterWithInitialRoutes function we wrote above, as the initialEntries prop.

Step 1. Define `initialRoutes` in `customRender`

It’s important to have a default initialRoutes of ["/"], since MemoryRouter spews errors if the array is empty. We can take care of that default in customRender (no matter what the options array may or may not contain) like so:



const initialRoutes =
  options && options.initialRoutes ? options.initialRoutes : ["/"];

Step 2. Pass `initialRoutes` to `MemoryRouterWithInitialRoutes` function

Then we can pass our newly-defined initialRoutes to MemoryRouterWithInitialRoutes (along with the default args, so the function can still access children):



return render(ui, {
  wrapper: (args) =>
    MemoryRouterWithInitialRoutes({
      ...args,
      initialRoutes,
    }),
    ...options,
});

Step 3. Use `initialRoutes` parameter in `MemoryRouterWithInitialRoutes` function

and finally, MemoryRouterWithInitialRoutes can make use of initialRoutes:



const MemoryRouterWithInitialRoutes = ({ children, initialRoutes }) => {
  return (
    <MemoryRouter initialEntries={initialRoutes}>
      {children}
    </MemoryRouter>
  );
};

Initial Routes in Action

Whew, that was a lot of setup. The good news is, it’s relatively simple to use a in a test file. Let’s use it to test that the route does the right thing when we navigate to "/locations/berkeley" :



test("renders berkeley page", () => {
  render(<App />, { initialRoutes: ["/locations/berkeley"] });
  const berkeleyHeader = screen.getByRole(
    "heading",
    { name: /berkeley/i }
  );
  expect(berkeleyHeader).toBeInTheDocument();
});

Here, we’re looking for that Berkeley header that we should see at "/locations/berkeley" — and finding it!

Why App and not Locations?

You might be wondering: why do the above examples render the App component and not the Locations component? It turns out, when you remove components from the React Router Switch component, you don’t have access to the [match](https://reactrouter.com/web/api/match) object (which contains the URL params, along with other route information).

You can fix this by using useRouteMatch in Locations.jsx instead of useParams:



// useParams: will not work with rendering Locations component
// const { id } = useParams();

// useRouteMatch: will work with rendering Locations component
const match = useRouteMatch("/locations/:id");
const id = match && match.params && match.params.id
  ? match.params.id
  : null;

I would not recommend this, however, as it’s generally not a great practice to complicate your production code merely for the sake of tests.

Including the Router and other Providers

Remember MemoryRouterWithInitialRoutes ?



const MemoryRouterWithInitialRoutes = ({ children, initialRoutes }) => {
  return (
    <MemoryRouter initialEntries={initialRoutes}>
      {children}
    </MemoryRouter>
  );
};

This can be updated to add as many providers as you’d like. For example, if you want to add a Redux provider and a React Query provider:



import { Provider } from 'react-redux';
import { QueryClient, QueryClientProvider } from 'react-query';

const MemoryRouterWithInitialRoutes = ({ children, initialRoutes }) => (
const queryClient = new QueryClient();
  <MemoryRouter initialEntries={initialRoutes}>
    <QueryClientProvider client={queryClient}>
      <Provider store={store}>
        {children}
      </Provider>
    </QueryClientProvider>
  </MemoryRouter>
);

Note: You will have to create the* *store* for Redux the same way you would for the actual Provider (not included in the code above). The good news is, you can also use this temporary test *store* to set up initial state for your tests.

You might want to update the name of the function at this point from MemoryRouterWithInitialRoutes to Providers. 🙃

Conclusion

I hope this is enough to get you started with testing apps that use React Router. As you can see, the setup is not simple! Fortunately, once you have the MemoryRouter wrapping your render, it’s more straightforward to apply routes in the test functions.

Testing React: A convert’s journey from Enzyme to Testing Library

Bonnie Schulkin — Thu, 02 Jun 2022 22:34:53 +0000

Image by Shri ram from Pixabay

I’m a big tester. Testing has saved my bacon enough times that I feel uneasy coding without it, like rock climbing without a rope. Even if I’m in a gym and the floor is really springy, a rope (like testing) helps minimize the damage when things inevitably go wrong.

When I started learning React several years ago, Enzyme was all the rage for test rendering and DOM manipulation. I come from an old-school back-end testing background (meticulous unit testing and isolation). Enzyme seemed great! I could take the same testing approach with React, testing state and other implementation details to my heart’s content.

Then I started hearing about Testing Library (specifically testing-library/react). At first I was resistant: an opinionated library which enforced someone else’s ideas of “best practices”? My detailed unit testing approach was under threat! I steered clear.

As time went by, it became clear Testing Library was here to stay, so I thought I’d check it out. After trying it for one project (my personal website), I am a total convert. Read on for my reasons why.

Opinionated === Best Practices

Testing Library encourages your tests to interact with your code the same way your users would. For example: Find an element and click it. Then, instead of checking to see whether the state changed (sorry, not an easy option in Testing Library!), check to see whether the page changed in the way you expect.

This is known as testing behavior (what’s on the page) vs. testing implementation (internal state). After all, user experience determines whether your code is working according to spec — not what state happens to be.

The downside: when tests fail, there’s less granularity pointing to where exactly the tests failed (is the state the problem? Or is it something else in the onClick callback?). The upside: less test refactoring when your code changes. It’s a trade-off, but in front-end testing, I’m coming around to the “fewer, more robust tests” philosophy. The time spent tracking down errors is less significant than the time spent maintaining tests.

I’ve especially come to appreciate this in the past year or so as React has moved from class-based components to functional components with hooks. If the behavior doesn’t change from the user perspective, there should be little-to-no cause to update tests when updating the implementation. Trends in React will continue to evolve, and your app can evolve with them without requiring a major testing overhaul.

Accessible Code

Another opinion from Testing Library: how to find page elements in your tests. The recommended element specifier is role, which relies on the accessibility tree (aka how elements appear to screen readers and other accessibility tools). Using role to find page elements for tests makes sure you have accessibility at top-of-mind while creating your content.

You can also use Enzyme to find elements by role, but it is not nearly as easy: 1. You have to use the generic find method to find role attributes

You have to account for cases for all attributes that represent role (for example, aria-role and role)
You have to account for inferred roles (like the “button” role for a element).

In Testing Library, you get all these role indicators for free with the getByRole method.

jest-dom Assertions

Jest is pretty generic when it comes to assertions: You can test things like “does this variable have the right value?”, or “does this object have the expected property?”, or “was an error thrown?”, but there’s nothing specific to the DOM.

Testing Library’s jest-dom to the rescue! Let’s say you want to know whether an element is visible on the page. You could use Enzyme to see whether the element has the proper class, and use Jest’s toBe, like so:

expect(myElement.toHaveClass('hiddenClass')).toBe(true);

Or, you could use jest-dom’s [toBeVisible](https://github.com/testing-library/jest-dom#tobevisible) :

expect(myElement).not.toBeVisible();

By testing what the user sees (whether the element is visible, rather than whether it has a certain class), you’re testing behavior, you savvy tester, you.

There are also lots of other useful DOM specific assertions, for example: [toHaveFocus](https://github.com/testing-library/jest-dom#tohavefocus) and [toBeChecked](https://github.com/testing-library/jest-dom#tobechecked) . This makes for robust, concise, and extremely readable test code.

Since the jest-dom assertions do not work with Enzyme wrapper objects, they are not available to use in Enzyme (at least not in any way I could figure out). Another item in the “plus” column for Testing Library.

ESLint Plugins

To go even further in encouraging best practices, both testing-library and jest-dom have ESLint plugins to give feedback when you’ve gone astray.

For example, say you want to test that a checkbox is checked by default. You think to yourself, [toHaveAttribute](https://github.com/testing-library/jest-dom#tohaveattribute) is the way to go! So you type out your test:

Wait a minute… what’s that angry red line under toHaveAttribute? A mouseover reveals that [toBeChecked](https://github.com/testing-library/jest-dom#tobechecked) is preferred here. Nice way to be reminded of best practices (and even possibly learn a new assertion).

Helpful Hints on Roles

Sometimes it’s hard to know which role to specify when searching for elements. Never fear — if you search for an element by role and Testing Library can’t find it, the test output tries to steer you right. For example:

Ooh! So I guess that element has a role of ‘link’ and not a role of ‘heading.’ Thanks, Testing Library. 😁

Conclusion

I tinkered with Testing Library on a small project, and I can see why it’s gained so much momentum. The opinionated library encourages best practices such as testing behavior over implementation, and writing accessible code. Its jest-dom assertion library provides simple, readable tests. Finally, the ESLint plugins and test output help with best practices and finding elements. I am a big fan!

Photo by Enrique Zafra from Pexels

Testing Functions within Functional React Components

Bonnie Schulkin — Thu, 02 Jun 2022 22:29:44 +0000

People are switching to functional components in React, and class-based components are quickly becoming a thing of the past. However, with class-based components out of the picture, it’s much harder to access a function within your functional component for unit testing. A common question I get these days:

How do I test functions inside my functional component?

The short answer: you can’t. There is no way to access functions defined within a functional component for testing. But… if you’re reading this post, you probably don’t like that answer. Read on to see what your options are. 😊

Option 1: Don’t unit test the functions

Do any or all of the functions need to be unit tested? The trend in React testing these days is functional or behavioral testing, which means testing the interface between your app and your user. Unit testing functions means you’re testing internals (that is, testing your code, instead of testing your app). This is generally frowned upon because it makes your tests brittle and subject to rewriting upon refactor.

However, there are some cases where unit testing functions can be beneficial (for complex functions, or functions with edge cases that don’t affect the display layer). You can see this blog post for my recommendations on when to unit test within React apps. If these reasons fit your situation, take a look at the other options.

Option 2: Move Functions Outside the Component

Relocating functions to a custom hook makes them accessible for testing (plus you’re keeping business logic separate from the UI, in accordance with best practices). There’s even a library to help with testing custom hooks: react-hooks-testing-library.

Here’s an example of a custom hook with several related functions in my website code. Note that I don’t test this particular hook separately from the UI because it fits under this category in “When not to use the react-hooks library” : Your hook is easy to test by just testing the components using it.

Still, it’s an example of removing functionality from the functional component, so the component can focus solely on display. And I could access the functions within the hook for testing if they matched the reasons to use the react-hooks library:

You’re writing a library with one or more custom hooks that are not directly tied to a component
You have a complex hook that is difficult to test through component interactions

Option 3: Use Class-Based Components

This one might give you the heebie-jeebies — after all, you made a functional component to get away from the complexity of class-based components. However, you always have this option if the first two options don’t work for you. Class-based components served the React community well for many years, and they are still supported by React. And to the point of this blog post, you can easily access functions within a class-based component as a property of the component.

So there you have it: three options for testing functions within a functional component (none of which actually test functions within a functional component, since that’s just not possible).

Getting Started with Redux and Testing Library

Bonnie Schulkin — Thu, 02 Jun 2022 22:26:11 +0000

Photo by Piret Ilver on Unsplash

If you’re reading this, I’m guessing you’re testing a Redux app with Testing Library. And you probably want some tests to start with the Redux store in a particular state as the initial testing conditions.

As you probably know, Testing Library emphasizes “testing behavior” (tests that interact with your app the way users would). Behavioral testing purists would say: to set up a Redux store with certain values, start the test by running through user interactions that populate the state.

However, that’s simply not practical to do for every test, especially if the desired state needs a lot of interactions (and possibly server values) for setup. This blog post details how to set up a store factory to generate a test store (with initial values) for test setup.

Creating a Store Factory

The idea here is, you have a “factory function” to create a new store. This function creates the store for both production and tests to make sure your tests are as close as possible to production code.

Examples

Here’s an example of a store factory function using Redux Toolkit and Redux Saga:

import {
  Action,
  configureStore,
  EnhancedStore,
  ThunkAction,
} from "@reduxjs/toolkit";
import createSagaMiddleware from "redux-saga";

export const createStoreWithMiddlewares = (
  initialState = {}
): EnhancedStore => {
  const sagaMiddleware = createSagaMiddleware();

  const store = configureStore({ YOUR REDUCERS HERE },
    middleware: (getDefaultMiddleware) =>
      getDefaultMiddleware().prepend(sagaMiddleware).concat(YOUR MIDDLEWARES HERE),
    preloadedState: initialState,
  });

  sagaMiddleware.run(YOUR ROOT SAGA);

  return store;
};

Here’s another one using Redux and Redux Thunk:

import { createStore, applyMiddleware, Store } from "redux";
import ReduxThunk from 'redux-thunk';

export const middlewares = [ReduxThunk];

export const createStoreWithMiddlewares = (initialState = {}): Store => {
  return createStore(
    YOUR REDUCERS HERE,
    initialState,
    applyMiddleware(...middlewares)
  );
};

Both of these store factories have a createStoreWithMiddlewares function that takes an initialState and can be used to create either the production store or a test store — with the same configuration. You can use these examples to write a createStoreWithMiddlewares for your app.

Using the Store Factory: Production

The production store can be created using createStoreWithMiddlewares either in your store/index.js file or src/index.js, and added as the store prop to the Redux Provider.

It’s very important to add the Redux Provider in src/index.js and not in App.js! If App.js contains the Redux Provider with the production store, then you won’t be able to test the App component with your test store, since the actual production store will be used when you render <App />.

Using the Store Factory: Tests

Now that the production Redux Provider has been relegated to index.js, we have total control over the store for our tests. Follow these steps and delight in the power!

Step 1: Create a Custom Render Function

We can overwrite the Testing Library [render](https://testing-library.com/docs/react-testing-library/api#render) function with a custom render that includes a Redux Provider with a private store just for that test. Write this code in, say, src/test-utils/index.tsx (actual file location and name are not important. Also, if you’re not using Typescript, you’ll probably want to use index.jsx instead of index.tsx).

import { EnhancedStore } from "@reduxjs/toolkit"; // for redux-toolkit
// import { Store } from 'redux' // for non-toolkit
import {
  render as rtlRender,
  RenderOptions,
  RenderResult,
} from "@testing-library/react";
import { ReactElement, ReactNode } from "react";
import { Provider } from "react-redux";

import { configureStoreWithMiddlewares, RootState } from "../store";

type ReduxRenderOptions = {
  preloadedState?: RootState;
  store?: EnhancedStore; // for redux-toolkit
  // store?: Store // for non-toolkit
  renderOptions?: Omit<RenderOptions, "wrapper">;
};

function render(
  ui: ReactElement,
  {
    preloadedState = {},
    store = configureStoreWithMiddlewares(preloadedState),
    ...renderOptions
  }: ReduxRenderOptions = {}
): RenderResult {
  function Wrapper({ children }: { children?: ReactNode }): ReactElement {
    return <Provider store={store}>{children}</Provider>;
  }
  return rtlRender(ui, { wrapper: Wrapper, ...renderOptions });
}

// re-export everything
export * from "@testing-library/react";

// override render method
export { render };

(this code is adapted from the Redux Testing Docs). Note that the Typescript is different for Redux-Toolkit than for plain Redux; use the lines that apply to your project (or no Typescript at all if that’s your jam).

The idea with the above code:

The custom render in this doc takes a preloadedState and UI component.
The custom render wraps the UI component in a Redux Provider, with a store that contains the preloadedState.
The code exports everything from @testing-library/react and then overrides the render method, so this file can be used in place of the actual @testing-library/react module (as we’ll see when we use it).
When importing from this file instead of @testing-library/react, all the methods except render (such as screen or fireEvent) will come straight from @testing-library/react — except render, which has been replaced with our custom render.

Note that you can create a store beforehand and pass it to the render function, or you can use the default, which is creating a new store with your preloadedState, using all of the configuration from the configureStoreWithMiddlewares function that our production uses:

    store = configureStoreWithMiddlewares(preloadedState),

If you do create a store and pass it as an argument, it’s very important that a new store is created for every test (so that there’s no sharing of state between tests).

Step 2: Using custom render in tests

To use this custom render in a test, we’ll import from our test-utils/index.tsx file instead of from @testing-library/react.

Say you have a user profile page, that looks like this:

our web site has won numerous awards for our clean, spare style 😝

The UserProfile component might look something like this:

import { EnhancedStore } from "@reduxjs/toolkit"; // for redux-toolkit
// import { Store } from 'redux' // for non-toolkit
import {
  render as rtlRender,
  RenderOptions,
  RenderResult,
} from "@testing-library/react";
import { ReactElement, ReactNode } from "react";
import { Provider } from "react-redux";

import { configureStoreWithMiddlewares, RootState } from "../store";

type ReduxRenderOptions = {
  preloadedState?: RootState;
  store?: EnhancedStore; // for redux-toolkit
  // store?: Store // for non-toolkit
  renderOptions?: Omit<RenderOptions, "wrapper">;
};

function render(
  ui: ReactElement,
  {
    preloadedState = {},
    store = configureStoreWithMiddlewares(preloadedState),
    ...renderOptions
  }: ReduxRenderOptions = {}
): RenderResult {
  function Wrapper({ children }: { children?: ReactNode }): ReactElement {
    return <Provider store={store}>{children}</Provider>;
  }
  return rtlRender(ui, { wrapper: Wrapper, ...renderOptions });
}

// re-export everything
export * from "@testing-library/react";

// override render method
export { render };

You can see that the user piece of state has name and email properties. To test that the user name and email show on the profile page, you need to preload the state with a user object for the test.

Here’s how the tests might look with our custom render method:

import { render, screen } from "../../test-utils"; // adjust for relative path to *your* test-utils directory 
import { UserProfile } from "./UserProfile";

const fakeUser = {
  name: "Tess Q. User",
  email: "tess-user@fake.domain.com",
};

test("User profile shows name and email", () => {
  render(<UserProfile />, { preloadedState: { user: fakeUser } });

  expect(screen.getByText("Tess Q. User")).toBeInTheDocument();
  expect(screen.getByText("tess-user@fake.domain.com")).toBeInTheDocument();
});

Here are the steps in the custom render method that make this work:

The custom render method uses the preloadedState option (and the createStoreWithMiddlewares function used in production) to create a new store.
The custom render method then creates a wrapper with a Redux Provider, passing the store with the preloaded state as a prop.
The custom render method uses the actual testing-library/react render to render the ui argument (in this case, <UserProfile />) wrapped in the newly-created Provider from step 2, and returns the result.

This result now has the store pre-populated with the specified user, the useSelector call in the component returns the fakeUser, and the tests pass.

Udemy, Enzyme and React 18

Bonnie Schulkin — Thu, 02 Jun 2022 22:14:42 +0000

Photo by Sigmund on Unsplash

I’ve gotten some questions about my Udemy course on Enzyme in light of the React 18 release, so I wanted to write an article with my thoughts.

Enzyme and React 18

tl;dr: Enzyme is not compatible with React 18, and probably never will be. I recommend React Testing Library instead.

The History

I started writing the Udemy course in March 2018, and it was published in May 2018. At that time, Enzyme was the primary option for testing React components with Jest. React Testing Library (Enzyme’s current prime competitor) had just been released in March 2018.

Since that time, a few things have happened:

In June 2020, Enzyme switched from being maintained by Airbnb to being maintained by an individual.
In October 2020, React 17 was released.
Also in October 2020, an unofficial Enzyme adapter for React 17 was released.
In December 2021, the author of the unofficial adapter for React 17 wrote an article entitled Enzyme is Dead, where he stated that he would not be writing an adapter for React 18.
In March 2022, React 18 was released.
In April 2022, the Enzyme maintainer has stated that he will work on a React 17 adapter before a React 18 adapter.
As of June 2022, the official adapter for React 17 has not been released.

Why I currently recommend React Testing Library

React Testing Library and Enzyme do the same job: rendering components so that they can be tested with Jest. I recommend React Testing Library over Enzyme for these reasons:

Unlike Enzyme, React Testing Library does not rely on React internals. This means React Testing Library does not have an adapter that needs to be updated with each release of React, and is far less likely to have issues with new React versions.
I find React Testing Library to be easier to use than Enzyme.

What all this means for the Udemy course

Now that React 18 has come out and there’s no React 17 adapter in sight, I don’t believe there’s a future for Enzyme. I would not recommend this course for people who are looking to learn how to test new React applications. Instead I would recommend you find a course on React Testing Library. (I have a recommendation 😂 — see my website for coupons)

That said, there are still around 2.1 million downloads of Enzyme a week (as of June 2022). Here are the circumstances under which I would recommend learning Enzyme:

You are working on a legacy project that already has a large suite of Enzyme tests, and the project never intends to upgrade to React 18.
You are working on a project with a large suite of existing Enzyme tests, and you wish to understand these tests before migrating to React Testing Library (RTL). However, Wojciech Maj, the author of the unoffiical Enzyme adapter for React 17, suggests:

While Migrate from Enzyme support article is available, I suggest you to just start fresh, forgetting that Enzyme has ever existed. RTL is by no means an Enzyme drop-in replacement, so having a completely fresh mindset will help you getting the most of it.

The Bottom Line

Enzyme was a great way to test React applications when this course came out; however, I can no longer recommend it. I encourage you to study React Testing Library instead.

ESLint, Prettier and VSCode Troubleshooting

Bonnie Schulkin — Thu, 02 Jun 2022 21:54:48 +0000

ESLint and Prettier can make coding so much easier with VSCode. I can’t tell you how many mistakes it catches in my code that are easily fixed in the moment — but would be difficult to track down as bugs later on.

But what if your problem is getting ESLint / Prettier to work with VSCode? See below for some troubleshooting tips. I’ve sorted the tips into three general symptoms:

Symptom 1: VSCode does not highlight errors
Symptom 2: VSCode does not format on save
Symptom 3: ESLint generates hundreds of “Delete ␍ prettier/prettier error"s

Symptom 1: VSCode does not highlight errors

Let’s say you’ve gotten ESLint and Prettier set up, but VSCode is not highlighting errors:

Here are some things to look into:

1. ESLint and Prettier installation

Make sure ESLint and Prettier are installed for your project.

2. ESLint Plugin for VSCode

Make sure the ESLint plugin for VSCode is installed and enabled.

3. ESLint Configuration File

Make sure you have an ESLint configuration file at the top level of your project.

4. eslint-plugin-prettier

I strongly prefer to use eslint-plugin-prettier and configure Prettier within my ESLint configuration file (rather than maintain two configuration files).

5. VSCode Default Formatter Setting

Make sure the default formatter in VSCode Settings is set to ESLint. Check both the User settings and the Workspace settings (Workspace takes precedence over User).

6. VSCode “Workspace” Directory

Make sure the directory you opened in VSCode (aka the workspace) is the top level of your project. For example, say:

your project lives at /usr/src/my-project
your ESLint configuration file is at /usr/src/my-project/.eslintrc.json

If you open any directory other than /usr/src/my-project as the workspace in VSCode (for example /usr/src or /usr/src/my-project/client), then VSCode won’t recognize the ESLint configuration file.

7. ESLint Configuration Errors

Check for ESLint configuration errors: open the VSCode Terminal, go to the Output tab, and choose ESLint from the dropdown:

8. ESLint overrideConfigFile Configuration

Check to see whether you have an ESLint overrideConfigFile option in VSCode settings. If this option exists, make sure there’s a configuration file in that location.

9. ESLint Working Directories in VSCode

Check to see if your file is excluded from the ESLint Working Directories in your VSCode User or Workspace settings.

Symptom 2: VSCode does not format on save

1. VSCode “Format on Save” settings

Make sure your VSCode settings:

have “Format on Save” enabled
have “Format on Save Mode” set to “file”

2. VSCode “code actions on save” setting

Make sure your VSCode settings include ESLint in the “code actions on save”:

In settings.json, there should be an entry like this:



"editor.codeActionsOnSave": 

  {

    "source.fixAll.eslint": true

  },

Not all ESLint errors are “auto-fixable”

Note that some ESLint errors won’t be auto-fixed on save, because they are not auto-fixable. To use eslint-plugin-testing-library as an example, this error:

auto-fixes to this on save:

But this linting error:

is not auto-fixable, so doesn’t update on save.

Symptom 3: ESLint generates hundreds of “Delete `␍` prettier/prettier error”

This might occur if you are on a Windows computer, but the code was generated on a Mac or Linux computer. The error might also look like this:

Here are some things to try:

1. Run `prettier` from the command line

Run prettier on all of the files in the project (reference: create-react-app docs):



./node_modules/.bin/prettier --write "src/*/.{js,jsx,ts,tsx,json,css,scss,md}"

Update the prettier/prettier “endOfLine” rule

Update the prettier/prettier rule in the ESLint configuration file (reference: StackOverflow):



"prettier/prettier": [

  "error",

  {

    "endOfLine": "auto"

  }

],

Set line endings in VSCode settings

Set the line endings in .vscode/settings.json (reference: StackOverflow):



{

    "files.eol": "\n",

}

Update your global git settings

WARNING: this will update your global git settings and will affect ALL of your git projects.

Run git config --global core.autocrlf true and pull the code from GitHub again (or possibly re-clone the repo). (Reference: GitHub docs)

5. Consider using Windows Subsystem for Linux

Anecdotally, I did not get this error on my Windows laptop when using Ubuntu 20.04 on Windows Subsystem for Linux (even though other Windows users -- who were likely using PowerShell -- reported the error for the same GitHub repository).

DEV Community: Bonnie Schulkin

Why are functional tests so much longer than unit tests?

Functional Tests vs Unit tests

Example of a long(ish) functional test

The test

Why not make three separate tests?

What about a beforeEach?

Reasons NOT to use a beforeEach

Conclusion

When to unit-test your React app

Unit tests can be functional tests

Unit tests help diagnose other failing tests

Unit tests confirm data sent to the server

Unit tests for edge cases that don’t affect render

Summary

Testing React Apps that use React Router

Our App

What if using a test router feels too artificial?

The Locations Component

Example code for the Locations component

Including Router Context when Testing

Uh oh

The Solution

Testing Location URL params

Using a function for the render wrapper

Passing initial entries to the wrapper function

Step 1. Define initialRoutes in customRender

Step 2. Pass initialRoutes to MemoryRouterWithInitialRoutes function

Step 3. Use initialRoutes parameter in MemoryRouterWithInitialRoutes function

Initial Routes in Action

Why App and not Locations?

Including the Router and other Providers

Conclusion

Testing React: A convert’s journey from Enzyme to Testing Library

Opinionated === Best Practices

Accessible Code

jest-dom Assertions

ESLint Plugins

Helpful Hints on Roles

Conclusion

Testing Functions within Functional React Components

Option 1: Don’t unit test the functions

Option 2: Move Functions Outside the Component

Option 3: Use Class-Based Components

Getting Started with Redux and Testing Library

Creating a Store Factory

Examples

Using the Store Factory: Production

Using the Store Factory: Tests

Step 1: Create a Custom Render Function

Step 2: Using custom render in tests

Udemy, Enzyme and React 18

Enzyme and React 18

The History

Why I currently recommend React Testing Library

What all this means for the Udemy course

The Bottom Line

ESLint, Prettier and VSCode Troubleshooting

Symptom 1: VSCode does not highlight errors

1. ESLint and Prettier installation

2. ESLint Plugin for VSCode

3. ESLint Configuration File

4. eslint-plugin-prettier

5. VSCode Default Formatter Setting

6. VSCode “Workspace” Directory

7. ESLint Configuration Errors

8. ESLint overrideConfigFile Configuration

9. ESLint Working Directories in VSCode

Symptom 2: VSCode does not format on save

1. VSCode “Format on Save” settings

2. VSCode “code actions on save” setting

Not all ESLint errors are “auto-fixable”

Symptom 3: ESLint generates hundreds of “Delete ␍ prettier/prettier error”

1. Run prettier from the command line

Update the prettier/prettier “endOfLine” rule

Set line endings in VSCode settings

Update your global git settings

5. Consider using Windows Subsystem for Linux

Step 1. Define `initialRoutes` in `customRender`

Step 2. Pass `initialRoutes` to `MemoryRouterWithInitialRoutes` function

Step 3. Use `initialRoutes` parameter in `MemoryRouterWithInitialRoutes` function

Symptom 3: ESLint generates hundreds of “Delete `␍` prettier/prettier error”

1. Run `prettier` from the command line