Testing Styled Components

Let’s check how our tests are doing, starting with Carousel:

Currently, the test implicitly assumes that CarouselSlide only has the props it receives from Carousel. That assumption no longer holds now that CarouselSlide has default props. Let’s update the test to account for those:

Now move on to the CarouselSlide tests:

This is a longwinded way of saying that the first child of the CarouselSlide wrapper element is no longer an <img> element. Instead, it’s an instance of the Img component. That component does render an <img> element, but since this is a shallow test of CarouselSlide, the behavior of other components is treated as an unknown.

The problem is we now have two components defined in CarouselSlide.js: CarouselSlide, and the locally defined Img component. We need to expose Img so we can reference the component in tests. For reasons that will become clear in the next section, let’s expose Img by making it a prop. That is, CarouselSlide will take a prop named Img, and the existing Img component will be the default value of that prop. This will give us our final CarouselSlide.js for the chapter:

​①​

PropTypes.elementType, newly added in [email protected], validates that the prop is a valid argument to React.createElement: either the name of a DOM element (such as "div"), or a component.

Exposing the Img component provides a direct solution to the failing type() test:

With that fix in place, there’s one remaining CarouselSlide test failure:

The error message is Enzyme’s way of telling us that wrapper.find(’img’) didn’t match anything. Recall that we’re using shallow rendering, which means that find() only looks at the React tree that CarouselSlide’s render() method returns. Before this chapter, render() returned a tree that contained an <img> element. Now it doesn’t. Instead, it returns a component whose render() method returns an <img> element.

The fix is the same as the type() test—substitute the Img component for ’img’:

Now the CarouselSlide tests are all passing, and the component’s coverage is as good as ever. But the Img component itself has no coverage. Although the component is very simple, it’s always a good idea to use tests to validate assumptions. Right now, there are two important assumptions here:

1. The imgUrl prop is passed down to an Img instance as the src prop
2. The Img component renders an <img> element with the given src prop

Because we’re interested in the DOM output of the component, we should use Enzyme’s mount() to test these assumptions instead of shallow():

Like shallow(), mount() takes a React tree, renders it, and returns a wrapper that lets you make queries about that tree. Unlike shallow(), mount() fully renders the tree to the DOM. The Enzyme wrapper’s containsMatchingElement() method conveniently answers all of our questions about the component in one go. For more information on mount(), check out the official docs.^[61]

A word of caution about mount(): by providing the entire DOM tree rendered by a component, including DOM elements produced by nested components, mount() ignores the principle that components should be tested in isolation (see ​Mantra: Test One Piece at a Time​). In this case, though, the component being tested comes from a third-party library. What goes on under the hood isn’t really our concern; we just want to know that it creates the markup its API promised. Used sparingly, mount() tests like this one can be a healthy supplement to shallow() tests, particularly when using React components from another project.

Now your tests cover everything we need to know about the markup that CarouselSlide renders. The only thing left to test is the styles themselves. Commit your work before moving on:

Making Assertions About Styles

To make assertions about the styles that styled-components generates, you’ll need the Jest styled-components plugin.^[62] Install jest-styled-components with npm:

Then you’ll need to bring in the plugin before running your tests:

Now you have a new assertion at your disposal, toHaveStyleRule(). Add a test to the describe(’Img’) block to make sure that the expected styled.img styles are coming through:

Those tests should all come through green. Now add another test to confirm that the imgHeight prop works as expected. Since the default value is numeric, try a string value:

Once again, all tests should be green. Time for a commit:

Now let’s try out one of styled-components’ coolest features: extending styled components. If you pass an existing styled component to styled(), it’ll return a new component with the styles from the original component plus the new styles. The new styles take precedence, so this is a convenient way to override existing styles and avoid the specificity wars that are endemic in large CSS projects.

Give it a try:

Now you can see why Img is exposed as a prop. Before, the only way for the CarouselSlide consumer to alter the styles on the <img> element (aside from height) would’ve been to craft a CSS rule that targets it with an img element selector. But with the Img prop, the consumer can take the default component, extend it with new styles, and replace the original. Not only does that make it easy to override the styles, it also gives them a hook for inserting event handlers, DOM attributes, or additional markup. One prop, infinite extensibility.

As it stands, someone using Carousel who wants to modify <img> would have to set Img individually on each slide data object. It’d be convenient to be able to set a single prop on Carousel for modifying Img across the board, similar to the defaultImgHeight prop.

Let’s switch back into TDD mode. Add some tests for both the as-yet-undefined defaultImg prop and the existing defaultImgHeight prop:

Then move to the implementation:

And commit:

At this point, let’s pause and reflect on what it means to have adequate test coverage for styles. In this section, we created a toHaveStyleRule() assertion for every style rule. For dynamic rules like height, that’s useful: any time props are converted into something the user can see, it’s worth making sure that conversion works as expected. But for static rules, toHaveStyleRule() is close to being a truism: “Test that x is x.”

Still, it’d be nice to have some kind of sanity check when restyling components. What if you had a tool that automatically generated a diff of the component’s styles before and after, allowing you to review and confirm that your changes reflect your intent? In the next section, you’ll learn how to do just that using a Jest feature called snapshots.

Taking Jest Snapshots

When you think of testing, you probably picture a list of assertions about your code, a sort of checklist of its functionality. Up to this point, all of the tests in this book have fit that description. But sometimes a picture is worth a thousand words. Or in this case, a piece of content generated by your code can be worth a thousand assertions. Seeing a diff of that content can bring your attention to problems you might never have thought to write an assertion for.

For our purposes, the content we’re interested in snapshotting is the DOM generated by CarouselSlide, along with the styles generated by styled-components. To do that, you’ll need to install one more package, enzyme-to-json:

enzyme-to-json takes the trees from Enzyme wrappers and converts them to the JSON format used for Jest snapshot testing, a process known as serialization. To tell Jest to use the package, declare it in the Jest config:

If you are using Wallaby.js, be sure that you restart it to bring in the updated Jest config.

Now add a test with a new assertion (courtesy of the jest-styled-components plugin), toMatchSnapshot():

Then try running it:

Jest created a new directory, src/tests/__snapshots__, with one file:

This provides a nice, clear picture of what CarouselSlide (shallowly) renders. Try taking a snapshot of the Img component, too:

Run the test and you’ll see another snapshot in the same file:

Beautiful! Now you can see that the generated markup is just as expected, and that the <img> element receives a className that confers the expected styles. (As is always the case with styled-components, the particular class name—c0 here—is arbitrary.)

These two snapshots are an excellent substitute for several of the existing tests about CarouselSlide’s markup. Removing those rather rigid tests will help make it easier to change the component’s markup in the future: instead of making changes to multiple failing tests, you’ll only have to confirm that the new snapshots reflect your intent.

Pruning the tests that are redundant with the snapshots yields the final CarouselSlide.test.js for this chapter:

From now on, every time you run your tests, Jest will generate new snapshots to compare to the old ones. If the two are identical, the toMatchSnapshot() assertion passes. But what happens if they’re different? Try changing, say, the object-fit style rule from cover to contain:

When a toMatchSnapshot() assertion fails, Jest treats that as a test failure and shows you a diff of the snapshot. The snapshot on disk remains unchanged. To confirm that your change is intentional, you run the tests again with the -u (short for --updateSnapshot) flag, causing all snapshots to be overwritten.

This snapshot process may feel strange at first. Unit tests are normally automated. Snapshot testing, by contrast, requires human intervention: on its own, the machine can’t determine whether the test should pass or not. That brings human error into the equation. In practice, this downside is mitigated by the fact that snapshots are version controlled. If a pull request contains an unwanted change that’s reflected in a snapshot that the author carelessly updated, everyone reviewing that pull request will see the snapshot diff and have a chance to raise a red flag.

Speaking of version control, it’s time to make your final commit for this chapter:

This concludes our tour of styled-components and testing. We only got around to styling one element, the <img>, so there’s lots left to do! As an exercise for this chapter, try adding some finishing touches to the carousel. Play around with different styles for the caption, the buttons, and the overall layout. When you feel satisfied with your work, be sure to add a snapshot test for each element, then breathe a sigh of relief that your styles are safe from regressions.