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
babel
if 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-jest
and@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
React
components with React Testing Library -
Use
within
to avoid querying the entire document -
Waiting for appearance and disapperance of an element
-
Avoid
data-testid
if 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
msw
endpoint -
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, }, },