Does your React App React?
In the last 2 years, Concept Reply has seen rapid growth in its front-end projects. From being a pure back-end software factory to providing full stack IoT solutions, it has been quite a ride. Considering the value, a robust and responsive front-end adds to an IoT solution, it never came across as a surprise. However, venturing into thesnew horizons of front-end has presented its own set of challenges. One of them that we take very seriously at Concept Reply is Quality. In this article we briefly talk about the strategy we follow at Concept Reply to test and deliver the best possible front-end solution.
For those in the front-end world, there is no denying the fact that React is one of the most popular frameworks used to develop user interfaces. At Concept Reply, we use many other frameworks as well depending on the project and customer requirement. Some other frameworks we use are Angular, Vue, etc. For simplicity, we discuss the process we follow for a React based project. However, the main idea remains valid regardless of the framework.
React was created by Facebook and shot to fame in a relatively short span of time. The creators of React highlight three aspects which are core to its philosophy: Declarative, Component-Based and Learn Once, Write Everywhere.
1. Declarative: It enables users to create interactive UIs. It efficiently updates and renders components when data changes.
2. Component-Based: Individual components can be developed managing their own state and later encapsulated, reused or composed to make complex UI.
3. Learn Once, Write Everywhere: React can also render on the server using Node and power mobile apps using React Native.
Scenario for front-end testing in most cases:
One of the most neglected aspects of front-end development is unfortunately testing. In many situations, front-end testing is limited to running the application manually from the browser and performing a rigorous end to end test when the shipping date is close. On the contrary, back-end includes a plethora of unit tests with a minimum coverage as one of the points in the definition of done. However, as a best practice, front-end should also be developed with the same mindset as back-end, i.e., code must be tested. At Concept Reply, we have integrated front-end testing as a standard development process that recommends best practices in terms of code coverage, linting, etc. In the following sections we present some of the methods we employ to deliver a high quality front-end.
Solution: A detailed test process involving automated tests and best practices integrated in the deployment pipeline.
In the following section we describe the process we follow at Concept to ensure that the react application is also well tested like any other software.
React testing library
One of the major challenges of writing tests for React is to write maintainable tests that avoid implementation details of the components. At Concept we heavily make use of the React testing library. It is a light-weight solution for testing React components providing utility functions on top of react-dom and react-dom/test-util. The library provides features to access the actual DOM nodes rather than the rendered React components. This ensures that the tests resemble the way a user would use the software.
Let us consider the following 2 components as examples that are to be tested.
Unit test
It is used to test the individual component. We always strive to write as many useful unit tests as possible. The above shown components can be individually tested to see if they are rendered correctly. The first component renders a list of frameworks based on an array. Similarly, the second component renders a card with a given title, image and description. It is important to note that at this point we do not test if the interaction of the two components.
Integration test
It is important to note that unit tests ensure that the individual component works well in isolation. However, they may not be working as per the expectations together. In Image 1, for example, when the user clicks the button next to the individual item, it should render the component shown in Image 2 with the corresponding details. The integration test handles this. Hence, it is important to test the interactions among different components through this test.
End to End (E2E) testing using Cypress
The E2E testing is used to test the entire flow from start to the end making sure that the integration among all the internal as well as external interfaces are validated. Through the E2E testing, we simulate scenarios how users would use the system. One simple example could be as follows.
· The user logs in.
· The user creates a new item in the front-end framework component.
· The new item should be part of the list.
· The user can click on the newly created component.
· The user is directed to the detail component page.
At Concept, we have been heavily using Cypress.io for our E2E testing. Since E2E tests are expensive to maintain and run, our strategy has been to have a low number of E2E tests mainly focusing on the positive scenarios and test the negative cases in isolation. It is also worth mentioning that we also considered another popular UI testing framework Selenium. However, after testing both the frameworks we zeroed on Cypress for E2E testing. One of the main reasons behind the better performance of Cypress was that it executes in the browser and Selenium executes outside the browser.
Code quality
Another aspect that we take very seriously at Concept Reply is that code quality of the software. One of the best ways to ensure code quality is to review code before merging. At Concept Reply, code reviews are one of the major parts of development process. Apart from improving code quality, it also provides an opportunity to learn from other peers.
To make code reviews more efficient, we also introduced an automated tool known as SonarQube to perform static code analysis. It provides valuable inputs to developers about potential bugs, code smells and security vulnerability. This ensures that the developer can already see issues with the code with detailed explanation and fix it before submitting a merge request.
Conclusion
We strongly believe that just like any other software, front-end should also be tested. All the processes described above are integrated in our deployment pipeline. These set of quality checks ensures excellent project delivery thereby making sure that the react app reacts as expected!
