What is jest?
“Jest is a JavaScript testing framework designed to ensure correctness of any JavaScript codebase.” If you’re familiar with mocha for example, jest is a similar concept.
Why should we use jest and what’s the point of testing?
When we deploy our apps many people (in some cases millions of people) will end up using it in endless different ways. We want to ensure that all of those million different ways will work. When we build an app, sometimes it is hard to think of those edge cases- for example: A user tries to log in and for some reason the main page doesn’t render correctly, or maybe they refresh the page and the login/create component pops up for a brief second. Testing allows us to deal and eliminate all those edge cases to ensure smooth operation of our apps.
How to test?
First of all I’ll recommend taking a look at their docs: Jest.
If you’re like me and reading docs can be challenging, there are many good videos on YouTube that explain how to test. Here’s an example of how to create some basic testing:
First step assuming you already created a react app, go inside the app directory and in the terminal write:
npm i — save-dev @testing-library/react react-test-renderer
This will install jest for the development stage of your app (we don’t need it on the deployed version of our app).
If we want to get a nice organized report when we test, we can also add this to the packagejson file:
Now whenever we run npm test in the terminal we will get a nicely presented summary of the tests (such as how much of our app is covered by tests etc).
The next step will be to create a test file. A good practice is to create a directory called __tests__ (jest will know to look inside for test files). We then can create a specific test for a specific component. To do that we we need to use the same name as the component and add .test.js–for example assuming we have a Header component:
Header.test.js
Also note that React provides us with a free test file for the App component when we create a React app (we can remove it and start from scratch or just leave it).
We can now test that our test file works with this code :
//In Header.test.js
test(‘returns true’, ()=> {expect(true).toBe(true)})
If we run npm test we should be getting 1 passing test. This tells us that our
Test file is good to go– Congrats you just wrote your first test~!
Now let’s actually test our Header component:
In our Header.test.js file we need to import:
//in Header.test.js
import {render, screen} from ‘@testing-library/react’import Header from ‘./../Header’
(The Header location will depend on where your components are located in your app)
Then write:
test(“should render a header”, () => {render(<Header />);const header = screen.getByTestId(‘header’)expect(header).toBeInTheDocument()})
So what’s going on here?
The syntax is the way to write a test. In every test we can write many expectations with different varieties. The first argument is the test description. In my case I want to see that the component renders correctly. We then pass it an anonymous call back function, We render the component on the screen and we check to see if it’s actually on the screen. The getByTestId is one way we can grab specific elements. In this case, I added the attribute of testid to the div that returns from the header component. It looks like this:
//In Header.js componentreturn (
<div id=”web-header” data-testid=”header”>
.....)
This is how the test can find the specific element and check if it renders or not (note that there are many different ways to get an element- to see all the different ways and their usage checkout jest doc). If you did teh steps above correctly and run npm test, you should have another test passing– Congrats on writing your second test!