Testing Stateful Components

Both of the React components we’ve built so far are stateless: their render output is determined entirely by the props they receive, allowing us to express them as a single function. This has the advantage of simplicity. But a carousel is stateful: it needs to keep track of which slide it’s currently showing. In this section, we’ll take a TDD approach to building a Carousel component with internal state.

Start with a stub implementation of the component. Since functional components can’t have state, make it a subclass of React.PureComponent:

Using React.PureComponent instead of React.Component tells React that our component doesn’t need to be re-rendered unless its props or state change. It’s a good practice to keep components pure whenever possible, both for performance and for conceptual simplicity.

Add a skeletal test suite:

Now let’s outline some requirements for this component:

• The carousel keeps track of the current slide with a number, slideIndex.

• slideIndex is initially 0, meaning that the first slide is shown.

• Clicking the “Prev” button decreases slideIndex, wrapping around to the index of the last slide when it would go below 0.

• Clicking the “Next” button increases slideIndex, wrapping around to 0 when it would go above the index of the last slide.

• The carousel takes an array named slides and renders the slide indicated by slideIndex.

Translating these requirements into tests will help us figure out exactly how to implement them.

Testing State

Enzyme’s API for working with state is analogous to its API for working with props. Call wrapper.state(key) to get the piece of state corresponding to that key:

To satisfy this test, you need Carousel to attach a state object to itself when it’s instantiated. One way to do that would be to add a constructor(). However, you can do better using the “class properties” syntax, which let you define instance properties as if they were variables scoped inside of a class block:

This syntax isn’t supported out-of-the-box by @babel/preset-react or @babel/preset-env, but it’s become enormously popular in the React community. To add it to the project, install the @babel/plugin-proposal-class-properties plugin:

That addition yields the final package.json for the chapter:

Now add a plugins entry to .babelrc.js. Plugins listed there are combined with those provided by the presets:

With this added Babel plugin, Carousel’s initial state should work as intended. Now to make the component interactive!

Testing Event Handlers

To give the user a way to change the slideIndex, the Carousel component needs some buttons:

​①​

find() uses the CarouselButton component itself as a selector. The string ’CarouselButton’ would also work here, but string selectors are less reliable, since they depend on a detail of the target component (displayName) that’s otherwise hidden from you.

​②​

Since find() returns multiple results, at(index) is used to get a shallow wrapper around an individual button.

​③​

prop(’children’) returns what was passed as the children prop to the CarouselButton. Note that text() only works for DOM elements, not for components.

Jump to the implementation and add the buttons to the render tree:

Now we need to simulate click events on the “Prev” and “Next” buttons. Rather than relying on the relative order of the buttons in the render tree for every test, add data- attributes to make our test selectors more self-explanatory. The names of the attributes will have no effect on the functionality of the app. So, render the “Prev” button with data-action="prev" and the “Next” button with data-action="next", making it a breeze to target them with find(selector):

The simulate(’click’) calls trigger the onClick handler attached to the target node.

Now add the data- attrs (as props) to the buttons, along with click handlers:

​①​

The click handlers are defined using the same class property syntax used for state, which automatically binds them to the component instance. To put a finer point on it: new copies of state, handlePrevClick(), and handleNextClick() are created for every instance of Carousel.

​②​

Previously, we’ve used setState() with a state update object as its argument. Here, it’s given a callback instead. The callback receives the original state and returns an update object. This is a helpful approach for avoiding timing issues: setState() is asynchronous, so it’s possible in principle for multiple state changes to be queued up. If, for instance, a “Prev” click and a “Next” click both registered before the state changes flushed (unlikely but theoretically possible), the correct result would be for the two slideIndex changes to cancel each other out, which is exactly what the two callbacks would do.

With that, the tests should be green. Sharp-eyed readers will notice that the click handlers don’t yet handle the case where slideIndex would go too low or too high and need to wrap around. In order to do that, Carousel needs to know how many slides there are. Which brings us to our final Carousel feature: rendering the slides.

Manipulating State in Tests

So far, the carousel is just a pair of buttons. What it really needs is some slides. A simple approach to this is to give the Carousel instance an array of data as a prop called slides, then pass the data from slides[slideIndex] as props to a CarouselSlide.

Replace the existing beforeEach block to set the slides prop on the Carousel instance, then add a (failing) test for the slide-passing behavior:

​①​

The new test uses a method called props() instead of prop(). This method returns an object containing all of the node’s props.

​②​

Recall that toEqual() does a deep comparison of two objects, whereas toBe() does a strict equality check. Strict equality would fail here; there’s no way to replace all of a component instance’s props with a different object, even if we wanted to. Instead, what we’re checking is: “Does this component have all of the props from slides[0], and no other props?”

​③​

Enzyme’s setState() method works analogously to setProps(), merging the given object into the component’s existing state.

Then update the render method in Carousel to satisfy the test:

​①​

The ...slides[this.state.slideIndex] spread passes every key-value pair in the object into the <CarouselSlide>, satisfying our test.

Having slides as an array also allows us to solve the slideIndex “overflow” problem: in the Next click handler, you can use slides.length as an upper bound and wrap to 0 when the new index would collide with that bound. Conversely, in the Prev click handler, you can wrap from 0 to the max value of slides.length - 1. Write some tests to make this concrete:

​①​

The original click handler tests are now in a describe() block to make their initial condition explicit, and two new describe() blocks have been added below it for the edge cases.

Now all you have to do is update the handlers:

​①​

The remainder operator (%) makes it possible to deal with the click handler edge cases succinctly.

One last thing: you’ll need to declare propTypes in order to make the linter happy. This time, use the static keyword to declare them as a static property within the class definition:

These prop types say, “slides must be an array of objects that each have the same shape as the propTypes declared by CarouselSlide.”

With that, this chapter’s Carousel is complete! Put a bow on it with a commit: