In those hard covet times, when most of the testing events are postponed or moved
In the first part of this series I discussed the importance of test automation and testing strategies, and why it is difficult to automate visual component testing. While it is not impossible to automate the visual quality assurance process, with the tools that are available to us today, the effort-to-return ratio is not particularly recommendable. Since this series deals with “pragmatic” testing strategies, let’s take a step back and try something else. Meaning, we’ll visually verify the results with our “eyes,” while automating the process of preparing the results to be verified as much as possible. Storybook, the tool I briefly introduced last week, is the most effective of the kind.
Like I mentioned in part one, Storybook is more of a UI development environment and playground for UI components than a testing tool. The main goal of Storybook is to enable developers to develop the UI component independently outside of the application. If you think about it, since the purpose of most of our testing tools is to help verify that “the module or a function can run appropriately in an independent environment,” Storybook can be considered to be a test as well.
(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.)