README.md

Testing

Test code is a first-class part of the deliverable, not an optional nice-to-have.
When scoping / estimating work: always factor in testing.
Testability is an attribute of good code. Code that cannot be tested is a problem.
Insufficient test coverage is better than no test coverage.
Prefer Use Case Coverage over Code Coverage (no need for 100% code coverage).
Additional history and guiding principles are in this "manifesto" doc

Organization of testing scripts in package.json (more details)
- npm run test: Runs all test runners (Jest and/or Cypress)
- npm run test:watch: Runs all test runners in watch mode
- npm run test:jest: Runs Jest and exits
- npm run test:jest:watch: Runs Jest in watch mode
- npm run test:cypress: Runs Cypress and exits
- npm run test:cypress:open: Open Cypress dashboard
Apply the AHA principle. Try to minimize nesting, coupling and over-abstraction. These make tests brittle and hard to maintain.

Unit test files for components should be siblings in the same directory with a .test.js suffix. Placing test code close to application code is intended to encourage testing and make it harder to forget.
For the test name, prefer the it('should do something') syntax because it is more self-documenting and intuitive
Use describe() and beforeEach sparingly. They lead to nesting and coupling.

Prefer the getByRole query over others because it typically best matches the user's experience. 1
Avoid getByTestId because it least matches the user's experience.
We encourage using the screen object exported by Testing Library because the resulting idioms will be more similar in React and Vanilla JS projects. 1, 2.