From 9663df6508d24d4ad2bb3e2c2dcd054722315fd1 Mon Sep 17 00:00:00 2001 From: Ryan Stephen Date: Mon, 10 Jun 2019 11:12:57 +0530 Subject: [PATCH] Update composite-component / grammar edit Changed tense "has" in line 219. Changed punctuation to "," in line 219. Added "," in line 223. Changed "more and more" to "many" in line 246. Added missing word "about" in line 248. --- content/react/en/composite-component.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/react/en/composite-component.md b/content/react/en/composite-component.md index ea70d75b8..dc58f52bf 100644 --- a/content/react/en/composite-component.md +++ b/content/react/en/composite-component.md @@ -216,11 +216,11 @@ Storybook stories paired with manual visual tests and snapshot tests (see above) However, sometimes the devil is in the details. A test framework that is explicit about those details is needed. Which brings us to unit tests. -In our case, we want our `TaskList` to render any pinned tasks **before** unpinned tasks that it is passed in the `tasks` prop. Although we have a story (`withPinnedTasks`) to test this exact scenario; it can be ambiguous to a human reviewer that if the component **stops** ordering the tasks like this, it is a bug. It certainly won’t scream **“Wrong!”** to the casual eye. +In our case, we want our `TaskList` to render any pinned tasks **before** unpinned tasks that it has passed in the `tasks` prop. Although we have a story (`withPinnedTasks`) to test this exact scenario, it can be ambiguous to a human reviewer that if the component **stops** ordering the tasks like this, it is a bug. It certainly won’t scream **“Wrong!”** to the casual eye. So, to avoid this problem, we can use Jest to render the story to the DOM and run some DOM querying code to verify salient features of the output. -Create a test file called `src/components/TaskList.test.js`. Here we’ll build out our tests that make assertions about the output. +Create a test file called `src/components/TaskList.test.js`. Here, we’ll build out our tests that make assertions about the output. ```javascript import React from 'react'; @@ -243,6 +243,6 @@ it('renders pinned tasks at the start of the list', () => { ![TaskList test runner](/tasklist-testrunner.png) -Note that we’ve been able to reuse the `withPinnedTasks` list of tasks in both story and unit test; in this way we can continue to leverage an existing resource (the examples that represent interesting configurations of a component) in more and more ways. +Note that we’ve been able to reuse the `withPinnedTasks` list of tasks in both story and unit test; in this way we can continue to leverage an existing resource (the examples that represent interesting configurations of a component) in many ways. -Notice as well that this test is quite brittle. It's possible that as the project matures, and the exact implementation of the `Task` changes --perhaps using a different classname or a `textarea` rather than an `input`--the test will fail, and need to be updated. This is not necessarily a problem, but rather an indication to be careful liberally using unit tests for UI. They're not easy to maintain. Instead rely on visual, snapshot, and visual regression (see [testing chapter](/test/)) tests where possible. +Notice as well that this test is quite brittle. It's possible that as the project matures, and the exact implementation of the `Task` changes --perhaps using a different classname or a `textarea` rather than an `input`--the test will fail, and need to be updated. This is not necessarily a problem, but rather an indication to be careful about liberally using unit tests for UI. They're not easy to maintain. Instead rely on visual, snapshot, and visual regression (see [testing chapter](/test/)) tests where possible.