The more your tests resemble the way your software is used, the more confidence they can give you.
> git clone [this repo]
# Open two terminal windows:
# Terminal 1
> cd api
> npm i
> npm run dev
# Terminal 2
> cd app
> npm i
> npm run dev
Super simple and trivial reminder/todo app.
- Do not use
babelif usingTypeScript:
there are some caveats to using TypeScript with Babel. Because TypeScript support in Babel is purely transpilation, Jest will not type-check your tests as they are run. If you want that, you can use ts-jest instead, or just run the TypeScript compiler tsc separately (or as part of your build process).
-
Use
ts-jest. See how to configure ts-jest -
Avoid common mistakes with
eslint-plugin-jestand@typescript-eslint/eslint-plugin// eslintrc.json "extends": [ ..., "plugin:jest/recommended", "plugin:@typescript-eslint/recommended" ],
-
Setup and teardown with
setupFilesAfterEnv// jest.config.js setupFilesAfterEnv: ['./jest-setup.ts'];
-
Testing
Reactcomponents with React Testing Library -
Use
withinto avoid querying the entire document -
Waiting for appearance and disapperance of an element
-
Avoid
data-testidif possibleit is recommended to use this only after the other queries don't work for your use case. Using data-testid attributes do not resemble how your software is used and should be avoided if possible.
-
Mocking API calls with
MSW -
Testing network errors by overriding
mswendpoint -
100% Code coverage 🔥🔥🔥
We know that 100% code coverage does not mean we're writing meaningful tests throughout; at least, it will give us immediate feedback that we are missing some tests.
// jest.config.js coverageThreshold: { global: { statements: 100, branches: 100, lines: 100, functions: 100, }, },