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

# Packaging an app with webpack

In the beginning, preparing JavaScript for the browser was simple. You would simply put your page’s functionality in a single script and load it with a `<script>` tag. Then jQuery took off, and your script had a dependency. No problem: jQuery + app = two `<script>` tags. But then other libraries came around, which depended in turn on other libraries. Using Backbone.js meant you had to load it after Underscore.js. As more app functionality moved into the browser, the once simple act of loading code in the right order became a challenge. And what about concatenating and minifying scripts for performance? What about loading “below-the-fold” scripts asynchronously? What about development mode?

Only a few years ago, bespoke in-house tools were the norm for addressing these problems. But now, at last, there’s a Swiss army knife for building JavaScript:  [webpack](https://webpack.js.org/) (always lowercase). Raw scripts go into webpack and compiled, concatenated, minified bundles come out. With a little bit of configuration (and unfortunately, sometimes a lot), webpack can generate any bundle you can imagine.

In this section, you’re going to harness the power of webpack to build a small demo app for the carousel component. 
* To get started, open the `test-driven-carousel` [project from the last chapter](https://www.educative.io/courses/test-driven-react-development/manipulating-state-of-stateful-component-in-tests). Then install `webpack` as a dev dependency along with `webpack-cli` and a library called `babel-loader` that lets webpack use Babel to compile scripts:

  ~~~sh
  $ npm install --save-dev webpack@4.26.1 webpack-cli@3.1.2 babel-loader@8.0.4
  + webpack@4.26.1
  + webpack-cli@3.1.2
  + babel-loader@8.0.4
  ~~~

* Then create a file called `webpack.config.js` in the root of the project:

  ~~~
  // webpack.config.js
  module.exports = {
    mode: 'development', // 1
    entry: {
      carousel: './src/Carousel.js', // 2
    },
    module: { // 3
      rules: [
        {
          test: /\.js$/,
          loader: require.resolve('babel-loader'), // 4
        },
      ],
    },
  };
  ~~~

><ol><li> Using <code>mode: 'development'</code> provides good defaults for running code locally, optimizing for ease of debugging at the expense of bundle size and runtime performance. By contrast, <code>mode: 'production'</code> would give you a minified bundle.</li></br><li>Each entry point defines a separate bundle for webpack to build. Here we’re telling webpack to build a bundle called <code>carousel.js</code> that contains <code>src/Carousel.js</code> and its dependencies.</li></br><li>The <code>module</code> block is where we tell webpack how to treat different kinds of modules via an array of </code>rules</code>. A “module” in webpack can be any kind of file(JSON, CSS, even images)but we’re only concerned with JS modules, so we have just one rule.</li></br><li>This rule says, “Use </code>babel-loader</code> for all <code>.js</code> files.” The loader will run each script through Babel with the config found in the root of our project.

* The `webpack-cli` package added an executable named `webpack`. When it runs, it looks for a config file to tell it what to do. Although it should find the `webpack.config.js` in the root of the project by default, make the connection explicit by passing it a `--config` flag in a new `build` script:

  ~~~Json
  // package.json
  ...
  "scripts": {
    "test": "jest",
    "lint": "eslint . && prettier-eslint --list-different **/*.js",
    "format": "prettier-eslint --write **/*.js",
    "build": "webpack --config webpack.config.js"
  },
  ...
  ~~~

* Now try building your project:

  ~~~sh
  $ npm run build
  Hash: ccc06a7f00b25a1780c4
  Version: webpack 4.26.1
  Time: 619ms
  Built at: 2018-12-02 18:48:29
         Asset     Size     Chunks             Chunk Names
  carousel.js  106 KiB  carousel  [emitted]  carousel
  Entrypoint carousel = carousel.js
  [./src/Carousel.js] 5.31 KiB {carousel} [built]
  [./src/CarouselButton.js] 269 bytes {carousel} [built]
  [./src/CarouselSlide.js] 1.46 KiB {carousel} [built]
      + 11 hidden modules
  ~~~

If you look in the `dist` dir of the project, you’ll see the `carousel.js` bundle. As the output indicates, that bundle includes `Carousel`, `CarouselButton`, and `CarouselSlide`.

Sharp-eyed readers will notice that the size of the bundle (106 KiB) is many times greater than the total size of the three carousel components. The gap is explained by the “hidden modules” mentioned at the end of the output. By default, webpack is silent regarding modules from `node_modules`. In this case, those modules are the imports from the `react` and `prop-types` packages. If you’re curious to see them, run `webpack` again with the `--display-modules` flag.

A bit of housekeeping before we continue. ESLint is unaware that `dist/carousel.js` is generated code, so it considers that code to be within its purview:

~~~sh
$ npx eslint .

/Users/tburnham/code/test-driven-carousel/dist/carousel.js
   16:24  error  Missing trailing comma                      comma-dangle
   45:48  error  'Symbol' is not defined                     no-undef
  ...

✖ 81 problems (81 errors, 0 warnings)
  36 errors and 0 warnings potentially fixable with the `--fix` option.
~~~

81 errors! Fortunately, ESLint allows you to ignore directories the same way that Git does, by listing patterns in an ignore file:

```
//.eslintignore
dist/
```
<embed file="code/ch4/.eslintignore" language="bash" />

It’s also a good idea to tell Prettier to ignore that directory:

```
//.prettierignore
dist/
```
<embed file="code/ch4/.prettierignore" language="bash" />

Additionally, if you’re using VS Code, you might consider adding `dist` to the `files.exclude` section of your Workspace Settings since you shouldn’t have to view or edit its contents directly:

```
//.vscode/settings.json
{
  "files.exclude": {
    "dist": true, 
    "node_modules": true, 
    "package-lock.json": true
  }, 
  "[javascript]": {
    "editor.tabSize":  
  },
  "editor.formatOnSave": true 
}
```

<embed file="code/ch4/.vscode/settings.json" language="jsx" />







Webpack

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

Webpack

Packaging an app with webpack