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 Tests
- Use React Testing Library.
- 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. - 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
ormixins/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', () => {})
- Do not use nested
-
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`', () => {})
- The message should be started with
- Mocks:
- The name of the mock function or constant should be started with
mock
word. (notmocking
, notmocked
)
- The name of the mock function or constant should be started with
Read More
- Runespoor Engineering Playbook
- Tap the Star on the Runespoor Stack repository to support us.
Top comments (0)