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

# Getting started with styled-components

As apps grow, they can contain thousands of style rules, too many for a single person to keep track of. This leads to unintended conflicts. For example, which of the styles below will apply to a disabled button with the `white` class?

~~~css
// StylesheetA.css
button.white {
  background-color: white;
  color: black;
}

// StylesheetB.css
button:disabled {
  background-color: grey;
  color: darkgrey;
}
~~~

The answer is that it depends on the order the stylesheets are loaded in, as both selectors have the same level of specificity. This is a very fragile state of affairs for a complex app. Worse, removing style rules becomes a risky endeavor. Let’s say that your app has this style rule:

~~~css
p.alert-message {
  color: red;
}
~~~

You search your codebase for `alert-message`, find no results, and so you remove the style. But your search didn’t match this React code:

~~~sh
<p className={`${urgency}-message`}>This is an alert!</p>
~~~

## Advantages of styled-components

The CSS-in-JS paradigm, exemplified by [styled-components,](https://www.styled-components.com/) greatly alleviates these problems by allowing a component’s style rules to be written as a function of its props. This offers a number of advantages:

* There’s no need to search your codebase to find out which styles are associated with a component. Its styles are either in the same module or imported like any other dependency.

* Styles are generated as a function of their component’s props and state, just like markup.

* Styles can be subjected to unit tests.

* Unlike the `style` prop, style rules generated by styled-components have the full range of functionality of ordinary CSS, including support for media queries, keyframe animations, and pseudo-classes.

 Let’s start adding some style to `test-driven-carousel`. Install the `styled-components` package as a dependency:

  ~~~sh
  $ npm install --save styled-components@4.1.1
  + styled-components@4.1.1
  ~~~

So far, this course’s methodology has been to present tests first, then the code to satisfy these tests. This is, after all, a course about TDD, and TDD is usually taken to mean “writing tests first.” But on a deeper level, TDD is about seeking useful feedback for your code as quickly as possible. Tests are just one possible source of feedback. And when it comes to styles, the most useful source of feedback is usually seeing those styles.

So set tests aside for now. All you’ll need for this section is a live dev server.



# Getting started with styled-components

As apps grow, they can contain thousands of style rules, too many for a single person to keep track of. This leads to unintended conflicts. For example, which of the styles below will apply to a disabled button with the `white` class?

~~~css
// StylesheetA.css
button.white {
  background-color: white;
  color: black;
}

// StylesheetB.css
button:disabled {
  background-color: grey;
  color: darkgrey;
}
~~~

The answer is that it depends on the order the stylesheets are loaded in, as both selectors have the same level of specificity. This is a very fragile state of affairs for a complex app. Worse, removing style rules becomes a risky endeavor. Let’s say that your app has this style rule:

~~~css
p.alert-message {
  color: red;
}
~~~

You search your codebase for `alert-message`, find no results, and so you remove the style. But your search didn’t match this React code:

~~~sh
<p className={`＄{urgency}-message`}>This is an alert!</p>
~~~

## Advantages of styled-components

The CSS-in-JS paradigm, exemplified by [styled-components,](https://www.styled-components.com/) greatly alleviates these problems by allowing a component’s style rules to be written as a function of its props. This offers a number of advantages:

* There’s no need to search your codebase to find out which styles are associated with a component. Its styles are either in the same module or imported like any other dependency.

* Styles are generated as a function of their component’s props and state, just like markup.

* Styles can be subjected to unit tests.

* Unlike the `style` prop, style rules generated by styled-components have the full range of functionality of ordinary CSS, including support for media queries, keyframe animations, and pseudo-classes.

 Let’s start adding some style to `test-driven-carousel`. Install the `styled-components` package as a dependency:

  ~~~sh
  $ npm install --save styled-components@4.1.1
  + styled-components@4.1.1
  ~~~

So far, this course’s methodology has been to present tests first, then the code to satisfy these tests. This is, after all, a course about TDD, and TDD is usually taken to mean “writing tests first.” But on a deeper level, TDD is about seeking useful feedback for your code as quickly as possible. Tests are just one possible source of feedback. And when it comes to styles, the most useful source of feedback is usually seeing those styles.

So set tests aside for now. All you’ll need for this section is a live dev server.



Styled Components

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

Styled Components

Getting started with styled-components