This article was first published on Official TenX Blog - Medium
Recently we wrote about the frontend engineering standards in TenX. This standard gives us a chance to work with incredible libraries out there, such as React Native, Expo, and TypeScript. We also shared a little bit about how we do testing for our relaunched TenX app. In this article, we’ll be digging deeper into testing, especially UI testing, and how we developed a tool that make this process easier.
Background: Snapshot testing using Jest
We use Jest as the testing framework for our TenX app. This library meets our needs as it provides filtering, watch mode, and other cool ways to run our tests automatically.
Another cool thing this library supports is snapshot testing — a very useful tool for making sure your UI does not change unexpectedly. It compares the structure of the current UI with the saved structure that was previously generated. With one easy command, you can start seeing how your layout is rendered and compare the differences.
Limitations in relying solely on snapshot testing
This is a great UI testing method, which we even implemented for our E2E API test! However, we found some limitations in relying solely on snapshot testing:
- If a snapshot test breaks, developers tend to update the snapshot directly in order to fix the test without knowing the actual impact to the UI.
- When fellow engineers are reviewing the code that includes snapshot changes, they tend to “just approve” it because it is hard to tell what the difference really is.
Our requirements beyond snapshot testing
We also wanted a tool with these specific features in addition to snapshot testing:
- Quick, automated reference for each screen, which would be useful if we have changes in a component that affect a lot of screens.
- Regression test to make sure that future changes won’t ...
To keep reading, please go to the original article at:
Official TenX Blog - Medium