Gain insights into Test-driven Development with React. Learn unit and integration testing using Jest and Enzyme, and explore tools like ESlint, Prettier, Babel, Webpack, and Travis CI.

react.tar.gz

intro

intro-copy

ch3-something

generic

ch3-1

ch3-2

ch4-1

ch2-1

ch2-2

ch2-3

ch5-copy

intro-copy-wmhr0i

ch3-1-copy

ch4-1-copy

ch4-1-copy-2

generic-copy

ch4-copy

This course is a deep dive into testing in React. You will learn unit testing and integration testing using tools such as Jest and Enzyme. You will also learn about other tools such as ESlint, Prettier, Babel, Webpack, and Travis CI that add convenience for coding and testing.

Test-driven Development with React



We’ve seen how Babel can bring new features like JSX syntax to JavaScript. But Babel’s language-bending abilities can also be used for subtler purposes, tailoring your code to the needs of specific libraries. That’s what the official styled-components Babel plugin does. It’s a recommended addition for any project that uses styled-components.

* Install the plugin with npm:

  ~~~sh
  $ npm install --save-dev babel-plugin-styled-components@1.9.2
  + babel-plugin-styled-components@1.9.2
  ~~~

* Then add it to your Babel config:

  ~~~
  // .babelrc.js
  module.exports = {
    presets: ['@babel/preset-react', '@babel/preset-env'],
    plugins: [
      '@babel/plugin-proposal-class-properties',
      'babel-plugin-styled-components',
    ],
  };
  ~~~

* Restart your dev server, and inspect the element again:




<imagedata fileref="images/img-after-babel.png" border="yes"/>

Notice the difference? For one thing, the short class name has changed. (To reiterate: *never* copy class names generated by styled-components into your code) But more importantly, the formerly `sc-` prefixed class name is now prefixed with `CarouselSlide__Img-`. Thanks to the Babel plugin, you can now see the module name (`CarouselSlide`) and component name (`Img`) associated with every element styled by styled-components. Note, however, that the short class name is still the one used as the selector.

The Babel plugin also brings efficiency improvements, including the removal of comments and unnecessary whitespace from inside of your template literals. This allows you to write your styles in a human-friendly way without having to worry about the impact on your users’ limited bandwidth.

# Linting styles with Stylelint

Once you’re used to writing code with a powerful linter like ESLint, working without a linter can feel like performing on a trampoline without a net. The slightest error can have dramatic effects. That applies to CSS just as it applies to JavaScript. One typo can ruin the look of an entire page. Worse, because browsers vary widely in how they interpret CSS syntax, malformed style rules may work as intended in your preferred development browser but spawn visual bugs in others.

Thankfully, it’s possible to use the popular stylelint CSS linter on styles written for styled-components. Since ESLint ignores the contents of those template literals, the two linters have no trouble peacefully coexisting. In fact, they go together like chocolate and peanut butter.

* You’ll need a few packages for this: `stylelint` itself, `stylelint-processor-styled-components` to tell stylelint which parts of the file to read, `stylelint-config-recommended` to enable a reasonable set of default rules, and `stylelint-config-styled-components` to disable some rules that don’t apply in the land of styled-components. Install them as dev dependencies:

 ~~~sh
 $ npm install --save-dev stylelint@9.9.0 \
 stylelint-config-styled-components@0.1.1 \
 stylelint-config-recommended@2.1.0 \
 stylelint-processor-styled-components@1.5.1
 + stylelint@9.9.0
 + stylelint-config-styled-components@0.1.1
 + stylelint-config-recommended@2.1.0
 + stylelint-processor-styled-components@1.5.1
 ~~~

* Then create a `.stylelintrc.js` file in the project root:
 ```
 //.stylelintrc.js
 module.exports = {
 processors: ['stylelint-processor-styled-components'],
 extends: [
 'stylelint-config-recommended',
 'stylelint-config-styled-components',
 ],
 };
 ```
<embed file="code/ch4/.stylelintrc.js" language="session" />

* As with ESLint, you’ll want to tell the linter to ignore the `dist` dir:
 ```
 //.stylelintignore
 dist/
 ```
<embed file="code/ch4/.stylelintignore" language="session" />

* One more step. Add `stylelint` to the project’s `lint` script. To keep the line length in `package.json` manageable, split the script into two parts. Call the existing script `lint:js`, call the `stylelint` script `lint:css`, and run them both from the `lint` script:
 ```json
 //package.json
 "scripts": {
 "test": "jest",
 "lint:js": "eslint . && prettier-eslint --list-different **/*.js", 
 "lint:css": "stylelint **/*.js",
 "lint": "npm run lint:js && npm run lint:css",
 "format": "prettier-eslint --write **/*.js",
 "build": "webpack --config webpack.config.js",
 "dev": "webpack-dev-server --config webpack.config.js --open"
 },
 ```

 >1. By default, stylelint doesn’t know what kind of files to look at. The glob argument `**/*.js` tells it to look at the project’s JS files.

There should be no output (aside from npm’s) if you run the script, indicating that everything is copacetic right now:

~~~sh
$ npm run lint

> test-driven-carousel@1.0.0 lint /Users/tburnham/code/test-driven-carousel
> npm run lint:js && npm run lint:css

> test-driven-carousel@1.0.0 lint:js /Users/tburnham/code/test-driven-carousel
> eslint . && prettier-eslint --list-different **/*.js

> test-driven-carousel@1.0.0 lint:css /Users/tburnham/code/test-driven-carousel
> stylelint **/*.js
~~~

If you’re using VS Code, you’ll want to install the [stylelint extension by Shinnosuke Watanabe](https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint) to automatically lint as you type.

From now on, any style code you write will enjoy the benefits of linter coverage. Make a commit:

~~~shelll
:wrench: Initial stylelint setup
~~~

The stylelint configuration here is just a starting point. For a complete list of rules supported by stylelint that you might want to add to your project, check the official docs.

> Default props in shallow tests This course advocates testing components in isolation, and the example code given here is written with that principle in mind. Nevertheless, that principle was violated in this chapter when the addition of `defaultProps` to the `CarouselSlide` component broke a test against the `Carousel` component. How alarmed should you be?Not very. `defaultProps` is a singular exception to the rule that code from components other than the one being tested is not executed during shallow testing. `propType` validation also occurs on all components in the shallow render tree, so you’ll see console errors when a shallowly rendered component passes invalid props down.

>You can run the commands stated above in the following terminal:

Learn how to debug better using the Babel plugin and style better with Stylelint.


Before We Begin

Test-Driven Development with Jest

Integrated Tooling with VS Code

Testing React with Enzyme

Styling in JavaScript with Styled-Components

Refactoring with Higher-Order Components

Continuous Integration and Collaboration

Conclusion

Babel Plugin and StyleLint