Bruno Antunes has a series of videos on React Testing. The “setup” environment for Typescript and React is a huge time saver. Also may need to refer to RTL docs or Jest docs.
E2E testing: Automated instead of manual.
Integration vs Unit: Kent C. Dodd’s take, “Don’t care about distinctions…It’s about code satisfying the business requirements.”
Example of car on an assembly line. We test the engine before putting it in the car. Who cares what type of test.
What is mocking? Battery in the car. Test shouldn’t rely on the battery because it might be dead so the battery gets connected to a power outlet so we can test the engine.
When and why to test? High probability and high risk. You may use some sort of “risk assessment matrix.” As an example, the Amazon user profile picture customization doesn’t need to be tested but their shopping cart absolutely does.
The pyramid of testing maybe taught in undergrad is E2E at the top, Integration in the middle, and Unit at the bottom. But this is kind of BS, as it is more like a diamond. Creator of NextJS, Guillermo Rauch, has said, “Write tests, not too many. Mostly integration.”
Another line by Kent C. Dodds, “If you have to delete your tests after refactoring then what good did they do to you?!”
Bruno’s personal example of error in testing. He was testing the implementation of “axios” and they moved to “fetch” and it broke all their tests. So do not test implementation details, test the public interfaces or the public API, (the components and the props they receive).
Why not use default create-react-app or default next-js setup? Need tests with typescript need to fail compile time?
npx create-next-app yourProjectName --ts
// cd into project
npm install --save-dev jest typescript ts-jest @types/jest
npx ts-jest config:init // creates "jest.config.js" file
Note: In NextJS, Bruno always creates an “src” folder and moves the “pages” folder into that folder. I’ve seen a lot of developers do this in Create-React-App but not as much in NextJS. Surprised it doesn’t mess up file-based routing.
Create a “test” script in “package.json” to run your tests.
"test": "jest"Note: Running “npm t” is the same as “npm run test” just more concise
Create a simple test to make sure jest and ts-jest is working. Make sure it passes with accurate types and fails with inaccurate types.
export function sum(a: number, b: number) {
return a + b
}
// in sum.test.ts file
import { sum } from "./sum"
test("Adding 5 and 2 will return 7", () => {
expect(sum(5, 2)).toBe(7)
})Install react-testing-library
npm install --save-dev @testing-library/react
// but Bruno also likes to install userEvents and testing-library/dom and jest-dom
npm install --save-dev @testing-library/user-event
npm install --save-dev @testing-library/dom
npm install --save-dev @testing-library/jest-domNote: as of 6/3/22 @testing-library/react v13+ doesn’t support React <=17. So, for React >=18 -> @testing-library/react >=13+ and for React <=17 -> @testing-library/react <=12.1.5. Source: Stack Overflow.
npm i -D @testing-library/react@12.1.2Create another test with react component
Test fails in error because with Next, in the “tsconfig.json” file the “jsx”:”preserve” line (cost Bruno a few hours). To solve this create a “tsconfig.jest.json” file to extend “tsconfig.json” and override that “jsx” property with this snippet:
{
"extends":"./tsconfig.json",
"compilerOptions": {
"jsx": "react-jsx"
}
}*Note: this file could be called “tsconfig.test.json” but Bruno likes to have a separate one for cypress and jest.
The test will still fail in error because you need to tell “ts-jest” and jest that you have this new “tsconfig.jest.json” file. Intrcutions found in the “ts-jest” docs and see in the options menu they have “tsconfig” which shows you how can override the “ts.config.json” file. Copy and paste into “jest.config.ts” file as an additional property:
globals: {
'ts-jest': {
tsconfig: './tsconfig.jest.json',
}
}The test still fails because also in the “jest.config.ts” file, the “testEnvironment” property is set “node”, and needs to be changed to “jsdom” which we need to install.
import { render, screen } from "@testing-library/react"
import Hello from "./Hello"
test("renders 'Hello World'", () => {
render(<Hello />)
const myElement = screen.getByText("hello World")
expect(myElement).toBeInTheDocument()
})Search google for “setupFilesAfterEnv,” to have jest run once before running and tests. Copy and paste this line from docs:
setupFilesAfterEnv: ['./src/jest.setup.ts']
Note: As mentioned earlier Bruno has his components and pages in an “src” folder so he added this to the file path.
Now create a new “jest.setup.ts” file, and import ‘@testing-library/jest-dom’
At this point you should have configuration set for Jest and react testing library.
Bruno says the ESLint config is just as important as the Jest and react testing library. Docs here.
Run “npm init @eslint/config” and ESLint will start to ask a few questions in your console.
Note: Bruno used a “.js” file but it seems there is less warnings with a “.json” and the syntax is very similar.
In the newly created and automatically generated “.eslintrc.js” file, in the “extends” property add “next”, and “next/core-web-vitals” as values in that array.
Then delete the “env” object and the “plugins” object.
Add back a plugin in the “extends” area to enforce even more type checking:
“plugin:@typescript-eslint/recommended-requiring-type-checking”
Make sure there is a “lint”: “next lint” script in the “package.json” file and run.
Then back in “eslintrc.js” go to the “parserOptions” field and add “project”: “./tsconfig.json”
Note: I ended up with the following error after this step: “Error: Parsing error: “parserOptions.project” has been set for @typescript-eslint/parser.” Also:
The file does not match your project config: pages\api\auth[…nextauth].js.
The file must be included in at least one of the projects provided.
Adding “”**/*.js”” to the “include” property array inside the “tsconfig.json” file solved the warning”. I also think this may just need to be a pages\api\auth[…nextauth].ts file.
Disable an ESlint rule (may do this a few times)
"rules": {
"@typescript-eslint/explicit-module-boundary-types": "off"
}At this point I ran into an error that “Failed to load config “next” to extend from” and this was fixed by installing:
npm i --save-dev eslint-config-nextBut then running the linter I got a ton of ESLint errors because I am implementing this whole process on a deployed project. Great that it is working but bad that there is a lot of work to be done. These are all the rules disabled, using the process above, in order to get to “No ESLint warning or errors.” A lot.
"@typescript-eslint/explicit-module-boundary-types": "off",
"@typescript-eslint/no-unsafe-assignment": "off",
"@typescript-eslint/no-unsafe-member-access": "off",
"@typescript-eslint/no-unsafe-argument": "off",
"@typescript-eslint/no-unnecessary-type-assertion": "off",
"@typescript-eslint/no-non-null-assertion": "off",
"@typescript-eslint/restrict-template-expressions": "off",
"@typescript-eslint/no-explicit-any": "off",
"@typescript-eslint/no-floating-promises": "off",
"@typescript-eslint/no-unsafe-call": "off",
"react/no-unescaped-entities": "off",
"@typescript-eslint/require-await": "off",
"react/jsx-key": "off",
"no-inner-declarations": "off",
"react-hooks/exhaustive-deps": "off",
"@typescript-eslint/restrict-plus-operands": "off",
"@typescript-eslint/no-misused-promises": "off",
"react-hooks/rules-of-hooks": "off",
"no-empty": "off",
"no-useless-catch": "off",
"react/jsx-no-comment-textnodes": "off",
"testing-library/render-result-naming-convention": "off",
"react/jsx-no-target-blank": "off",
"@typescript-eslint/no-unsafe-return": "off",
"@typescript-eslint/no-inferrable-types": "off",
"prefer-const": "off"Here is the link for disabling rules.
Even after disabling the rules this way they are still showing up.
Also, not sure why my “eslintrc.js” has properties not wrapped in quotes unlike Bruno. Even if I add them in prettier is stripping them out.
From NextJS docs, “ESLint also contains code formatting rules, which can conflict with your existing Prettier setup. We recommend including eslint-config-prettier in your ESLint config to make ESLint and Prettier work together.”
The above step resolved the issue
This next step is only needed if using a “src” folder like Bruno. Configure NextJS project structure with ESLint because ESLint is only looking at a few folders by default (“pages”, “components”, and “lib”) and not the “src” folder. Resolve by adding “–dir src” to the “lint” script in the “package.json” file.
Now add the plugins for jest and RTL to get ESLint errors/warnings specific to these libraries and use the proper matchers. These are small details but can save you time.
Install via “npm install eslint-plugin-jest –save-dev”
Want use both “recommended” and “style” config since “all” is not fully stable at the time of recording.
This is done by adding to the “.eslintrc.js” file, in the “extends” property, “plugin:jest/recommended” and “plugin:jest/style.”
Bruno used an example of “fit” instead of “it” to focus test and have the ESLint error throw a warning.
Install the react-testing-library eslint plugin and add the corresponding plugin value to the “eslintrc.js” file.
npm install --save-dev eslint-plugin-testing-library"plugin:testing-library/react"An example of something this plugin shouldn’t like is using screen.debug() which is similar to a console.log triggering an “Error: Unexpected debug statement” from ESLint.
Note: as of 7/27/2022 I received the following warning: Test environment jest-environment-jsdom cannot be found. Make sure the testEnvironment configuration option points to an existing node module. As of Jest 28 “jest-environment-jsdom” is no longer shipped by default, make sure to install it separately.
npm i jest-environment-jsdomCreate a lint stage so we can use GitHub Actions to run ESLint on every commit we do.
npx mrm@2 lint-stagedNote: this installs “husky,” sweet package I’ve seen before.
npm install lint-staged prettier --save-devNow in the “husky/pre-commit” file change “npx lint-staged” to be “npm run lint-staged” and then in “package.json” file and confirm you now have a “prepare” script that runs “husky install” and add a “lint-staged” script that runs “lint-staged”
Down in the “package.json” file, in the “lint-staged” property, update “js”: “eslint –cache –fix” to be “*.(tsx|ts)”: “eslint –cache –fix”, and add underneath “*”: “prettier –write –ignore-unknown”
Bruno shows how making a commit will run prettier.
Note: I’m not sure why he doesn’t just run prettier on file save but instead on commit?
Note from NextJS docs: “If you would like to use “next lint” with lint-staged to run the linter on staged git files, you’ll have to add the following to the “.lintstagedrc.js” file in the root of your project in order to specify usage of the --file flag.”
From GitHub repo, click on Actions and create a new workflow by clicking on “More continuous integration workflows” and selecting “Node.js” update the name of the “.yml” file to whatever you desire.
Change branches from [main] to “*”
Change “runs-on” from “ubuntu-latest” to ${{matrix.os}} and define that matrix by adding, to the matrix property, a new “os” property and set to [ubuntu-latest, windows-latest, macos-latest ]
In the “steps:” property, change the “run:” that is set to “npm run build –if-present” to “npm run lint” and change “npm run test” to “npm run test:ci”
Then click start commit and add a commit “add github actions that will fail”
Google “jest code coverage threshold” to fail build if it doesn’t meet a given code coverage threshold. Copy code form Jest docs and paste into “jest.config.js” and update necessary values, (70% versus 80% etc.).
In the “package.json” file, add “test:ci” script that runs “jest –coverage –silent –ci”
Test Driven Development: TDD
Red Green Refactor
The goal for the React testing library is to test React components but focus less on the implementation details and more on the way your software is used. To prevent getting burned on a change. For example, class-based components moving to functional components. RTL is a replacement for Enzyme.
Grab/Query elements from the screen. There is a priority recommended. The best is getByRole, then getByText. Using the “data-testid” and “getByTestId” is the last priority but has its use cases.
Testing-playground.com
Do your tests based on the expected outcome, not based on the implementation.
Add a new file “Counter.spec.tsx” or “Counter.test.tsx”
test() is just syntactic sugar for it()
it("defaultCount=0, and + clicked then counter = 1", () => {
render(<Counter defaultCount={0} description="My Counter"/>)
expect(screen.getByText("Current Count: 0"))
expect(screen.getByText(/My Counter/i)).toBeInTheDocument
})Note: The test above uses regex in forward brackets and the /i is saying case sensitivity does not matter.
.todo can help you delay your test. they will show in separate color in the terminal.
fireEvent.click
grouping using describe() create sections and this helps to find tests easier.
use beforeEach() to run every time before the rest pf the group.
Add an “aria-label” attribute to the button and grab with getByRole
Add new feature using TDD.
Testing asynch code is where people struggle the most in their React testing journey.
What is async code? Clicking increment button and it calls to the server to see what the next number is, introducing some delay into your code. Other examples include using a setInterval or setTimeout or using a debounce when entering text into a text field. Need to wait for an action to happen before you test your code.
We don’t need to use “sleeps” like you may see in Selenium because RTL has “findBy Queries” which go asynchronously as compared to the “getBy” which go synchronously.
Note: There are “getBy, findBy, queryBy, getAllBy, findAllBy, queryAllBy” query methods.
“findBy” queries work when you expect an element to appear but the change to the DOM may not happen immediately.
The default interval is 50ms. However it will run your callback immediately before starting the intervals. The default timeout is 1000ms. This means that react-testing will test to see if something is in the DOM, and if not, will check again in 50ms.
Example 1:
use findBy query
convert previous example to have the click action in a “setTimeout” and this makes some tests fail because they immediately expect the counter to be one.
Note: How can you focus a test to have it run first? Use “.fit” instead of “.it” but know that the other “beforeEach” will still run.
fit('renders "Current count: 1"', async() => {
await waitFor(() => expect(screen.getByText('Current Count: 1')).toBeInTheDocument())
})Note: to only run the tests in one file use the command “npm t — yourFilename.spec.tsx”
Bruno prefers, when here are a lot “beforeEach”(s) depending on each other, to have the “beforeEach” to have all the logic regarding the waiting and doing actions. This way all you tests can just have the synchronous stuff and not in each “.it()” although not everyone will agree with this strategy.
~12.5 minutes
How you can wait for elements to be removed from the screen? For example, you do an http call and you have a spinner on the screen. How do you make sure the spinner was there and now you are waiting for it to disappear only when it disappears you want your test to pass?
Example 2: Add an element to act as a spinner that disappears once the counter gets to 15, 300ms after the http is done disappear.
Add some state to act as loading state.
it("renders too big, and will disappear after 300ms", async () => {
await waitForElementToBeRemoved(() => screen.queryByText("I am too small"))
})Note: waitForElementToBeRemoved will check to see if the element was ever there and then remove it. In the case of a loading spinner it may not show until a fecth button is clicked and then when the http request is finished updates the state to remove the loading spinner.
You set a variable named “id” using let. It is later assigned to a “setTimeout.” What type should you use next to id?
useEffect(() => {
let id = NodeJS.Timeout
id = setTimeout(() => setLoading(false), 300)
return function tearDown() {
clearTimeout(id)
}
}, 300)How can run a single test in a single file using jest? instead of runnign all of your tests, or even all of the tests in one file?
use the fit() keyword and npm t –yourFileName.spec.tsx
React may throw warning if we are trying to access/test a component after is has been unmounted/destroyed. Need a cleanup function that clears the timeout.
As an example let’s say you increment a value in state when a button is clicked but that update function is in a setTimeout. Your tests will fail because the value does not update immediately.
When you focus a test with the .fit keyword will the beforeEach’s still run? Yes
findBy returns a promise so can use await keyword
default interval 50ms
default timeout 1000ms
syntactic sugar on top of waitFor
getBy and findBy queries return what when they don’t find a match?
throw an error. queryBy just returns null.
Example #1:
Always want Math.random() to return a specific value so you can run your test.
jest.spyOn(Math, "random").mockReturnValue(0.5)// toHaveBeenCalledTimes(1)
// toHaveBeenCalledWith()
// toHaveBeenLastCalledWith()“Spies keep for forever counts from the past so a lot of times you need to clear a mock (telling it to forget about the past) to make sure other tests don’t fail. This is often done in a “beforeEach()”.
// mockClear()
// mockReset()
// mockImplementation is an alternative to .mockReturnValue()
beforeEach(() => whatEvs.mockClear())Example #2:
Two parts, the first is just a button that calls an “onMoney” function. We want to test that when we click the button the function is called. There are two ways to do this. The first way involves asynchronous testing using “done” keyword. Pass “done” as a parameter and then later calling “done()”. The second way is to use from jest the “jest.fn()” syntax that can be called with “.toHaveBeenCalledTimes(1)” or “toHaveBeenCalledWith(33)”
//first way
describe('MyComponent', () => {
it('renders Material-UI grid with columnDefs and rowData', (done) => {
const myOnMoney = (n: number) => {
expect(n).toBe(33)
done()
};
render(<Example2 onMoney={myOnMoney} />);
fireEvent.click(screen.getByRole('button', { name: 'Give me 33 dollars' }));
});
})//second way
describe('MyComponent', () => {
beforeEach(() => {
mockedDataGrid.mockClear();
});
it('renders Material-UI grid with columnDefs and rowData', () => {
const myOnMoney = jest.fn();
render(<Example2 onMoney={myOnMoney} />);
fireEvent.click(screen.getByRole('button', { name: 'Give me 33 dollars' }));
expect(myOnMoney).toHaveBeenCalledTimes(1);
expect(myOnMoney).toHaveBeenCalledWith(33);
});
})The second part of the example is to mock a “DataGrid” component from material UI in which we mock this module to just render a div that says table. We also want to make sure we pass the appropriate props. As long as we pass the expected props we fully trust that the material UI team has done their tests, and so we don’t have to more than make sure we are sending the necessary props.
Bruno also mentioned the use of expect.objectContaining() to have required fields for the column of the DataGrid, helpful if you only care abouyt one or two of the properties you don’t need to list them all.
Another important thing to prevent this test from failing is to add an empty pair of curly brackets as a dependency array. This is because when react calls our components it does so in a context.
import { Example2, rows } from './Example2';
import { fireEvent, render, screen } from '@testing-library/react';
import { mocked } from 'ts-jest/utils';
import { DataGrid } from '@material-ui/data-grid';
jest.mock('@material-ui/data-grid', () => ({
...jest.requireActual('@material-ui/data-grid'), // get the module as is
DataGrid: jest.fn(() => <div>Table</div>),
}));
const mockedDataGrid = mocked(DataGrid);
// with the line above, now we can do the same things with the function
// toHaveBeenCalledTimes(1) and toHaveBeenCalledWith()
describe('MyComponent', () => {
beforeEach(() => {
mockedDataGrid.mockClear();
});
it('renders Material-UI grid with columnDefs and rowData', () => {
const myOnMoney = jest.fn();
render(<Example2 onMoney={myOnMoney} />);
fireEvent.click(screen.getByRole('button', { name: 'Give me 33 dollars' }));
expect(myOnMoney).toHaveBeenCalledTimes(1);
expect(myOnMoney).toHaveBeenCalledWith(33);
});
it('renders table passing the expected props', () => {
render(<Example2 onMoney={jest.fn()} />);
expect(mockedDataGrid).toHaveBeenCalledTimes(1);
expect(mockedDataGrid).toHaveBeenLastCalledWith(
{
rows: rows,
columns: [
expect.objectContaining({ field: 'id' }),
expect.objectContaining({ field: 'firstName' }),
expect.objectContaining({ field: 'lastName' }),
expect.objectContaining({ field: 'age' }),
],
pageSize: 5,
checkboxSelection: true,
},
{}
);
});
});Note: About jest.fn(), we can pass this as a prop to simplify our tests, and just test the links between code by erasing the actual implementation of a function. See below:
it("render the comp passing the expected props", () => {
render(<WhatEvCompExpectingProps onMoney={jest.fn()} />)
})Example #3:
Similar to example 2 but about “swipeable drawer” from material-ui. Github. He received request to specifically mock this component.
import { render, screen } from '@testing-library/react';
import React from 'react';
import { MyDrawer } from './Drawer';
import user from '@testing-library/user-event';
jest.mock('@material-ui/core', () => ({
...jest.requireActual('@material-ui/core'),
SwipeableDrawer: jest.fn(() => <div>HELLOOOOOO</div>),
}));
describe('Drawer', () => {
it('shows no "Hello YouTube!"', () => {
render(<MyDrawer />);
expect(screen.queryByText('HELLOOOOOO')).toBeInTheDocument();
});
it('clicking on "Open Drawer" Button shows "Hello YouTube!"', () => {
render(<MyDrawer />);
user.click(screen.getByRole('button', { name: 'Open Drawer' }));
expect(screen.getByText('HELLOOOOOO')).toBeInTheDocument();
});
});I saw this code and thought it may be useful:
expect(screen.queryByText("Hello Youtube!")).not.toBeInTheDocument()Also this:
user.keyboard('{escape}')Example #4:
Similar to example 3 but we are going to mock something from our own application.
import { render, screen } from '@testing-library/react';
import { mocked } from 'ts-jest/utils';
import { MyDrawer } from '../Example3/Drawer';
import { Example4 } from './Example4';
jest.mock('../Example3/Drawer');
mocked(MyDrawer).mockImplementation(() => <div>mocked: drawer</div>);
describe('Example4', () => {
it('renders MyDrawer', () => {
render(<Example4 />);
expect(
screen.queryByText('Hello Drawer Component!')
).not.toBeInTheDocument();
expect(screen.getByText('mocked: drawer')).toBeInTheDocument();
});
});Example #5:
When requesting mock from very complex component (very deeply nested?). Uses “mocks” folder.
The test file:
import { render, screen } from '@testing-library/react';
import { Example5 } from './Example5';
jest.mock('../../VeryComplex/DeepFolder/DeeperFolder/VeryComplex');
describe('Example 5', () => {
it('renders very complex component', () => {
render(<Example5 />);
expect(screen.getByText('SIMPLE VERSION')).toBeInTheDocument();
});
});The component file:
import { VeryComplex } from '../../VeryComplex/DeepFolder/DeeperFolder/VeryComplex';
export function Example5() {
return (
<div>
<VeryComplex />
</div>
);
}Avoid using mocks for http calls. Use MSW, “mock service worker” library, (mswjs.io).
Avoid mocking axios or fetch with syntax like this:
jest.mock('axios')
// jest.spyOn(window, 'fetch')
const mockedAxios = mocked(axios);
const mockedAxiosGet = mocked(mockedAxios.get)
const mockedAxiosPost = mocked(mockedAxios.post)
/*
describe("PhotoList", () => {
beforeEach(() => {
mockedAxiosGet.mockResolvedValue({
data: [
{
id: 1,
thumbnailUrl: "/photo1.png",
title: "Hello World",
favorite: false,
},
[] as Photo[],
]
})
})
})
*/The reason to use MSW is making HTTP calls with Axios vs Fetch is an implentation detail so don’t we don’t base our test on that but base on the http call itself. If we ever change from fetch to axios we don’t invalidate our tests.
Install the MSW library and a polyfill:
npm install --save-dev msw whatwg-fetchUsing fetch with MSW will require a polyfill imported into your “jest.setup.ts” file.
import "whatwg-fetch"Note: in order to have a “jest.setup.js” file you need to add into your “jest.config.js” file the following line:
setupFilesAfterEnv: [".src/jest.setup.ts"]Here is the link to the examples.
Will use beforeAll() and afterAll() to start and stop server and likely afterEach() as well.
MSW Docs: How to Create our Mock Server:
https://mswjs.io they have a REST API example using TypeScript:
import { setupWorker, rest } from 'msw'
interface LoginBody {
username: string
}
interface LoginResponse {
username: string
firstName: string
}
const worker = setupWorker(
rest.post<LoginBody, LoginResponse>('/login', (req, res, ctx) => {
const { username } = req.body
return res(
ctx.json({
username,
firstName: 'John'
})
)
}),
)
worker.start()MSW HTTP Get Call – Create Mock Server:
Slightly different for Node:
import {setupServer} from "msw/node"
import {rest} from "msw"
const server = setupServer(rest.get('endpoint', (req, res, ctx) => {
return res(ctx.json([]))
}))Example #1: Spinner test and add delay to MSW response
Example #2: Type “Bruno” in search field and use query parameters
May need to wait for multiple calls to end to finish loading spinner. Instead of using loading state with true and false use how many calls are pending using a number. Another way is to cancel previous calls as they are made.
Example #3: Return 500 status code with MSW
Example #4: HTTP Post request with MSW
Uses .resetHandlers() and after seeing test passes, switches to fetch implementation and the test still passes.
Using fetch with MSW will require polyfill imported into jest.setup.ts file.
Create setupServer()
SWR does caching so may need to override with {dedupingInterval: 0, provider: () => new Map()} and to not repeat yourself you have two options: AllTheProviders or instead create a customRender (both from React Testing Lib).
multistep form
fireEvent.change but instead user from “@testing-library/user-event”
.type()
.click()
clickNextButton()
waitFor()
expect()
toHaveBeenCalledTimes(1)
formik validations are asynchronous, so there is a very slight delay.
refactor to use toHaveErrorMessage, require aria-errormessage and an id