How to write automation testing with React
1. I don’t use Enzyme
I use “React Testing Library” instead of “Enzyme”. The reason is that I want to test React.Hook.
https://testing-library.com/docs/react-testing-library/cheatsheet
yarn add --dev @testing-library/react
In my case, I make a simple wrapper class.
2. Use coverage effectively
The problem with testing is “where to start” and “how much testing to do”. Jest’s coverage is the good guideline.
View all coverage.
$ yarn test --coverage --watchAllView the coverage of one file.
$ yarn test CreateAction.test.js --coverageView only changed files.
$ yarn test --coverage
In my case, I write a test so that the “Uncovered Line” disappears. The components and redux modules (reducers + actions + operations) aim for 100% coverage. However, I will give up lines that do not know how to cover. In my opinion, modules testing is more important than components testing.
3. Snapshot test is must
Snapshot test is very easy and effective. So must write it.
4. Create a parent componet to use HOC
It is useful to create a parent class to enable HOC (High Order Component) in the test. The following is an example of a parent class. See the code above for the implementation on the child class.
5. Keep it() functions short
In implementing each test case, the most important thing is to clarify what it is for. The short it() function code makes it clear what the function is for. In order to shorten the function, use the initialization process in common by beforeEach() method.
In particular, toHaveBeenCalled () is important. This is a lot of bugs, please check carefully
6. Use “data-testid” attribute effectively.
Getting an element with the “data-testid” attribute dramatically simplifies your test code. According to the following article, it is better not to use the “id” attribute.
https://kentcdodds.com/blog/making-your-ui-tests-resilient-to-change
7. Use functions that dynamically generates dummy data.
I recommend that the dummy data be generated dynamically with a function. If you define dummy data as a variable, it will be affected by other tests. So I recommend creating new dummy data for each testcase each time.
8. Testing Redux containers
The easiest way is to export mapStateToProps and mapDispatchToProps. The operation of modules (e.g. signOut or changeAuthState) cannot executed, so the coverage is low.
9. Testing Redux reducers
The reducer is a function that takes the current state and action as arguments and returns the updated state. So, test the contents of the return value state.
10. Testing redux-thunk async actions
The async operations includes the process of dispatching multiple actions. So you test every dispatched action. The actual async function (eg:Auth.signIn) cannot be executed, so you use the mock function.
11. Overall sample code
See my GitHub repository.
https://github.com/kondows95/react-cognito-typescript-example