-
Notifications
You must be signed in to change notification settings - Fork 0
Unit Testing
We use Jest to run our test. We use React Testing Library along with the jest-dom assertion library to write our tests.
Gatsby provides an easy to follow tutorial for installing, configuring, and setting up your first test using Jest. Our set up does not diverge from this tutorial, but our tests themselves do.
React Testing Library is a collection of javascript utilities and helper methods designed to encourage test writing that matches how a user interacts with your app. Whereas a testing library such as Enzyme is predicated on testing your implementation of a react component, React Testing Library is predicated on testing how a user might interact with your app.
The more your tests resemble the way your software is used, the more confidence they can give you.
Writing tests that pass is easy. Writing tests worth having is hard. The first step is identifying what React components are worth testing. We are utilizing a Material UI React Component Library called react-md. It is not our responsibility to ensure those components preform in the way were designed (and/or as we would expect). It is our responsibility to test our implementation of those components. For example, we may have a nav
that have a collection of react-md
Button
components. Clicking each of those buttons does something
. Each of those buttons has a whole collection of props dictating their appearance and behavior. Now we will not test whether those buttons' appearance and behavior works as advertised, but we will test whether clicking each button does the something
our code says it should, and we will measure that effect on the DOM.
Don't bother testing that every single prop has the presentational effect you expect; Only test effects of the props (or state changes) that undergo significant manipulation or have measureable effects on the DOM or have a measureable effect on other props (or state changes).
The best way to add test coverage is to create new tests as you build new components. This is know as Test Driven Development (or Behavioral Driven Development) and it is, in a nutshell:
Write only enough of a unit test to fail
Write only enough code to make the failing unit test pass
In practice that looks something like:
- Identify a new necessary feature
- Write a test that describes that feature's success
- Verify that test fails (if it passes you either need to write a better test, or, congratulations, you're done!)
- Make the test pass (i.e. write code that adds the new feature)
- Verify the test passes
- Refactor (and if you do, verify the test still tests what you think it does, and re-verify the test still passes)
Think about writing tests from the perspective of the user: the user doesn't know about or care about state or prop changes, but they do know if they click on a button, or enter text into a form field, or really if they're ever presented with any oprotunity to interact with the DOM in any way, they expect something to happen. Write a test that describes cause and effect. These tests often take the form of Arrange, Act, and Assert:
- Arrange the elemnts you need to run your test
- Act on those elements to trigger whatever behavior you're testing
- Assert what outcome you expect from that behavior
React Testing Library
- Cheatsheet
- Composing Queries
- Firing Events
- Events API
- Async Utilities
- Special Considerations for simulating events
- How to test appear/dissapearing elements
- Great Examples
jest-dom