Re-post: Pragmatic Front-End Testing Strategies (3)
In part two of this series, we’ve dealt with using Storybook to automate portions of the visual testing. To refresh our memory, let’s recapitulate our Todo application’s processing stages.
- Display the default UI when the application executed.
- Retrieve the “Todo List” from the API server, and save it in the Redux store.
- Display the Todo List on the UI according to the value saved in the store.
- The user clicks on the input box, types in “Take a Nap,” and hits enter.
- Add “Take a Nap” to the Todo List in Redux store.
- Update the UI according to the new store value.
- Transmit the new store state over the server to synchronize.
These stages can mainly be categorized into two based on the “state of the application”. First, the stages 1,3, and 6 display the current state of the application to the UI. In part two of this series, we discussed why complete automation of such stages is difficult, and how we can use Storybook to facilitate the process.
Now, the remaining 2,4,5, and 7 compose the manipulation stages of the application’s state. Such stages can, again, be categorized into manipulating the state with the user input (4,5) and synchronizing the state of the client and the state of the server (2,7) The part three of this series will explore the traditional testing methods for such stages, and how Cypress fares against the traditional methods.
(Every code I wrote for this series can be found in my Github Repository. While the article will include all of codes that I think are critical for understanding, you can check out the repository if you are curious about the entire code.)
TOAST UI
