Testing Conventions

General conventions for tests

• Follow the Testing Trophy.
• Follow the Test Desiderata.
• Write tests. Not too many. Mostly integration..
• Follow the AHA testing.
• Separate the test cases. - One case - one test.
• Avoid mutable variables..
• Avoid nesting when you are testing.
• Keep tests up to date. - If you add the code for some method component/method/class, you should update all the current test cases and cover the new part of functionality with tests.
• Bad tests is worth than no tests. - If you don't know how to cover some functionality with tests, if you understand that your tests are bad - don't push 1-2 useless test cases to master!
• If you use TDD, you should follow the correct TDD flow.

Integration/Component Tests

• Use React Testing Library.
• Follow the priotiry of React Testing Library queries.
• Use the specified HTML ARIA-roles for ...ByRole() query.
• Use @testing-library/user-event for simulating user interactions.
• Avoid common mistakes with React Testing Library.
• Use custom render, renderHook that contains all the general Providers.
  • If you need some specific Provider, you can add it in the test case.
  • If you are going to use some Provider in the test case and understand that it is a global/general Provider - add it to the custom methods.
• Follow the Integration Testing Coverage.
• Do not test the implementation details in Integration tests.
• Do not use shallow rendering.
• Test components in isolation. Each test case should render the component from zero.

Mocking

The more your tests resemble the way your software is used, the more confidence they can give you.

• Understand that mocking is a tradeoff between speed and confindence.
• Do the mocks of server api calls correclty. Use msw for mocking REST api.
• Follow basic example of React Testing Library + msw API mocking.
• Turn off query retries for Tanstack Query.
• Mock system Timezone to remove the uncpected behavior with date. See the Vitest example.
• Your mocks should be organized in one style. - It is just as important as organizing your other code and files.

Style Guide

• Use mixins/jest or mixins/vitest from @runespoor/eslint-config.
• The test file should be located in the __tests__/unit or __tests__/integration folder, depending on the tests type. - It will help to run unit and integration test separatly.
• The tests should be located in the same folder as the component/method/class you are testing.
• The name of the test file should be the same as the component/method/class you are testing, but with the .test suffix.
• describe:
  • Do not use nested describe.
  • The message should be the name of the component/method/class your are testing.
  • Example: describe('useEntitiesMap', () => {})
  • Use separte describe for covering corner cases in the same testing file. It might be useful when you fix bugs and want to decrease the bugs repetition.
    • Example: describe('useEntitiesMap (corner cases)', () => {})
• it:
  • The message should be started with should word.
  • The message should be in the present tense.
  • Use ` ` quotes for all the technical names (props, args, handlers, hooks, etc.).
  • Example: it('should skip the entity if it does not have an object by the provided `entityDataPath`', () => {})
• Mocks:
  • The name of the mock function or constant should be started with mock word. (not mocking , not mocked )