Unit Testing: back to basic

I was recently playing with a simple React component and writing Unit Tests for that. The component was very simple like adding an user with name and age.

I was writing the test later because, initially unit testing was not the focus.

By looking at the component you will see that there are four methods and addUserHandler is the most interesting method where we have some input validation logic. So, naturally, you will try to test that with different combinations of enteredUsername and enteredAge to satisfy all the combinations. I found it difficult to check React's state and solutions available over internet were bit tricky. Using React Testing Library there was no straight forward solution for that. However, in the first run I wrote some of them but, accessing state mandated it to be converted from functional to class based component, which I did not want. So, was I doing something wrong?

Yes! What I was trying to do is asserting the internal implementations of a component, which I realized again when the state variable name change forced changing of the unit tests. Since, effectively we are not changing any component behavior, hence test should not be touched while refactoring.

So, what should we test? Go back to the basic. React component is a function which returns something. So, test that something and testing will be like a breeze.

Note that we are testing what you see in the screen. So, you check the component with some inputs and how it gets rendered. You can check the negative test cases also in the same way.

So, the conclusion: Think what you should test, before you write the unit tests.

The full source code is available here: https://github.com/onlydevelop/react-sample01