{"id":1420,"date":"2017-07-31T21:03:51","date_gmt":"2017-08-01T04:03:51","guid":{"rendered":"http:\/\/www.bradleycbuchanan.com\/b\/?p=1420"},"modified":"2017-07-31T21:03:51","modified_gmt":"2017-08-01T04:03:51","slug":"clean-react-enzyme","status":"publish","type":"post","link":"https:\/\/www.bradleycbuchanan.com\/b\/clean-react-enzyme\/","title":{"rendered":"How to write clean React unit tests with Enzyme"},"content":{"rendered":"

Lately I’ve been writing a lot of UI in React<\/a> and testing a lot of that code using Enzyme<\/a> (running on Karma<\/a> with Chai<\/a> assertions). It’s a great combination, but I don’t think we (the JavaScript community) have got the idiom down yet. <\/p>\n

For example, I’ve been reading a lot of test cases that look like this<\/a>:<\/p>\n

\r\n\/\/ TeacherHomepageTest.js\r\nit('if there are no courses, RecentCourses component shows a SetUpMessage', () => {\r\n  const wrapper = mount(\r\n    <TeacherHomepage\r\n      announcements={[]}\r\n      courses={[]}\r\n      sections={[]}\r\n      codeOrgUrlPrefix=\"http:\/\/localhost:3000\/\"\r\n    \/>\r\n  );\r\n  const recentCourses = wrapper.childAt(4);\r\n  assert.equal(recentCourses.name(),'RecentCourses');\r\n  const coursesContentContainer = recentCourses.childAt(0);\r\n  assert.equal(coursesContentContainer.name(), 'ContentContainer');]\r\n  const coursesSetUpMessage = coursesContentContainer.childAt(5).childAt(0);\r\n  assert.equal(coursesSetUpMessage.name(), 'SetUpMessage');\r\n  assert.equal(coursesSetUpMessage.props().type, 'courses');\r\n  assert.equal(coursesSetUpMessage.childAt(0).text(), 'Start learning');\r\n  assert.equal(coursesSetUpMessage.childAt(1).text(), 'Assign a course to your classroom or start your own course.');\r\n  assert.equal(coursesSetUpMessage.childAt(2).name(), 'Button');\r\n  assert.equal(coursesSetUpMessage.childAt(2).props().href, '\/courses');\r\n  assert.equal(coursesSetUpMessage.childAt(2).props().text, 'Find a course');\r\n});\r\n<\/pre>\n
That’s one of the simpler React tests in our repo, with a lot of assertions cut for brevity – I’ve seen upwards of 50 assertions in a test case trying pin the exact DOM output of a React component.  Needless to say, these tests are not fun to write and they’re even worse to read.  Let’s turn this into a readable unit test together!<\/p>\n
Test where the logic lives<\/h2>\n
The first problem with the test above is that it’s not a unit test at all.  The test is supposed to be checking the TeacherHomepage<\/code> component, but the logic being tested – whether the SetUpMessage<\/code> gets rendered – lives in the RecentCourses<\/code> component<\/a>, so it should be tested there.  As a first step, let’s change this into a test case for RecentCourses<\/code>.<\/p>\n
\r\n\/\/ RecentCoursesTest.js\r\nit('shows a SetUpMessage when there are no courses', () => {\r\n  const wrapper = mount(\r\n    <RecentCourses\r\n      courses={[]}\r\n      heading=\"Recent Courses\"\r\n      showAllCoursesLink\r\n      isTeacher\r\n    \/>\r\n  );\r\n  const coursesContentContainer = recentCourses.childAt(0);\r\n  assert.equal(coursesContentContainer.name(), 'ContentContainer');]\r\n  const coursesSetUpMessage = coursesContentContainer.childAt(5).childAt(0);\r\n  assert.equal(coursesSetUpMessage.name(), 'SetUpMessage');\r\n  assert.equal(coursesSetUpMessage.props().type, 'courses');\r\n  assert.equal(coursesSetUpMessage.childAt(0).text(), 'Start learning');\r\n  assert.equal(coursesSetUpMessage.childAt(1).text(), 'Assign a course to your classroom or start your own course.');\r\n  assert.equal(coursesSetUpMessage.childAt(2).name(), 'Button');\r\n  assert.equal(coursesSetUpMessage.childAt(2).props().href, '\/courses');\r\n  assert.equal(coursesSetUpMessage.childAt(2).props().text, 'Find a course');\r\n});\r\n<\/pre>\n
Test as shallow as possible<\/h2>\n
That takes care of the layers above<\/em> the component under test, now how about the layers below<\/em>?  Right now our test is making several assertions about the behavior of SetUpMessage<\/code> but it would be better if the SetUpMessage<\/code>‘s own unit tests took care of that.  Once we’ve extracted those tests, we can make fewer assertions here… and we can use Enzyme’s shallow()<\/code> rendering<\/a> instead of mount()<\/code><\/a>.<\/p>\n
\r\n\/\/ RecentCoursesTest.js\r\nit('shows a SetUpMessage when there are no courses', () => {\r\n  const wrapper = shallow(\r\n    <RecentCourses\r\n      courses={[]}\r\n      showAllCoursesLink\r\n      isTeacher\r\n      heading=\"Recent Courses\"\r\n    \/>\r\n  );\r\n  const coursesContentContainer = recentCourses.childAt(0);\r\n  assert.equal(coursesContentContainer.name(), 'ContentContainer');]\r\n  const coursesSetUpMessage = coursesContentContainer.childAt(5).childAt(0);\r\n  assert.equal(coursesSetUpMessage.name(), 'SetUpMessage');\r\n  assert.equal(coursesSetUpMessage.props().type, 'courses');\r\n  assert.equal(coursesSetUpMessage.props().isTeacher, true);\r\n});\r\n<\/pre>\n
Extract default props<\/h2>\n
I find this makes a big difference for test readability.  Your component will have several required props, but you want your unit tests to check one thing – why not highlight the props that matter?  In our case the empty courses array is the pivotal factor in our test case.  Let’s extract the other props to minimize distractions.<\/p>\n
\r\n\/\/ RecentCoursesTest.js\r\nconst defaultProps = {\r\n  showAllCoursesLink: true,\r\n  isTeacher: true,\r\n  heading=\"Recent Courses\",\r\n};\r\n\r\nit('shows a SetUpMessage when there are no courses', () => {\r\n  const wrapper = shallow(\r\n    <RecentCourses\r\n      {...defaultProps}\r\n      courses={[]}\r\n    \/>\r\n  );\r\n  const coursesContentContainer = recentCourses.childAt(0);\r\n  assert.equal(coursesContentContainer.name(), 'ContentContainer');]\r\n  const coursesSetUpMessage = coursesContentContainer.childAt(5).childAt(0);\r\n  assert.equal(coursesSetUpMessage.name(), 'SetUpMessage');\r\n  assert.equal(coursesSetUpMessage.props().type, 'courses');\r\n  assert.equal(coursesSetUpMessage.props().isTeacher, true);\r\n});\r\n<\/pre>\n
Assert in JSX<\/h2>\n
It’s still awfully clunky to query our way down the tree of components and assert one property at a time.  Wouldn’t it be nice if we could just use JSX to describe the expected output of the component?<\/p>\n
Enzyme has a fairly powerful .containsMatchingElement(node)<\/code><\/a> method that lets you do exactly this.  It’s not obvious from the documentation, but you can pass a fairly complex JSX structure to compare to your wrapper.  All children must be present, but you can skip props you don’t care about for this test case (like the ContentContainer<\/code>‘s props here) and still get a match.<\/p>\n
\r\n\/\/ RecentCoursesTest.js\r\nit('shows a SetUpMessage when there are no courses', () => {\r\n  const wrapper = shallow(\r\n    <RecentCourses\r\n      {...defaultProps}\r\n      courses={[]}\r\n    \/>\r\n  );\r\n  assert(wrapper.containsMatchingElement(\r\n    <div>\r\n      <ContentContainer>\r\n        <SetUpMessage type=\"courses\" isTeacher \/>\r\n      <\/ContentContainer>\r\n    <\/div>\r\n  ));\r\n});\r\n<\/pre>\n
It’s that so much better?  It even gets a little tigheter with chai-enzyme<\/tt>‘s containMatchingElement<\/code><\/a> assertion, and it provides nicer output when the assertion fails.<\/p>\n
\r\n\/\/ RecentCoursesTest.js\r\nit('shows a SetUpMessage when there are no courses', () => {\r\n  expect(shallow(\r\n    <RecentCourses\r\n      {...defaultProps}\r\n      courses={[]}\r\n    \/>\r\n  )).to.containMatchingElement(\r\n    <div>\r\n      <ContentContainer>\r\n        <SetUpMessage type=\"courses\" isTeacher \/>\r\n      <\/ContentContainer>\r\n    <\/div>\r\n  ));\r\n});\r\n<\/pre>\n
I’ve been looking for React+Enzyme best practices online, but for some reason I can’t find any guides describing tests like this.  I’m not sure why – it’s so much nicer to write and read than what we started with.  If you’ve got other ways to improve on this pattern, please let me know.  Thanks!<\/p>\n","protected":false},"excerpt":{"rendered":"
Lately I’ve been writing a lot of UI in React and testing a lot of that code using Enzyme (running on Karma with Chai assertions). It’s a great combination, but I don’t think we (the JavaScript community) have got the idiom down yet.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24,8],"tags":[456,454,459,453,455,452,457,458],"class_list":["post-1420","post","type-post","status-publish","format-standard","hentry","category-featured","category-programmer","tag-chai","tag-chai-enzyme","tag-clean-code","tag-enzyme","tag-karma","tag-react","tag-tdd","tag-unit-testing"],"_links":{"self":[{"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/posts\/1420","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/comments?post=1420"}],"version-history":[{"count":18,"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/posts\/1420\/revisions"}],"predecessor-version":[{"id":1438,"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/posts\/1420\/revisions\/1438"}],"wp:attachment":[{"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/media?parent=1420"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/categories?post=1420"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bradleycbuchanan.com\/b\/wp-json\/wp\/v2\/tags?post=1420"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}