[Visual Testing]: Optimize the amount of snapshots taken by component #692
Labels
P3 - low
Priority: Stretch goal
TAG: dev experience
TODO: needs decisions
Further discussion and planning necessary
type: proposal
New feature or request
Product
KDS.
Context
The free Percy plan give us 5000 snapshots/month, so this means it charges per snapshot, no matter if the snapshot is large or small. At the time of writing this issue, this limit is not yet a problem, but if in the future we are close to reaching this limit, a way to optimize is proposed.
If we want to capture exhaustively all different combinations of a component, we would end up with many snapshots taken for just one component. For example, KButton among all its combinations of primary, secondary, flat, raised, link, disabled, with/without icon etc. has ~48 combinations, and each of those would end up in a used percy snapshot. And since KButton is a small component, in each snapshot we are left with a large part of the snapshot blank, having a lot of free space that we could use, and optimize the number of snapshots taken per component.
Desired behavior
For these "base states" with different props combinations, we could take another strategy and render multiple combinations of props on a single page, to spend only 1 snapshot for several base states. One Idea is to refactor the current visual renderComponent to allow something like:
And render all the different combinations of
propsCombinations
in a single grid, and use thegridItems
prop to set the span of each grid item.We can have this
renderComponent
flexible and allow also render just a given set of props for bigger components (like KModal where we will need to render just 1 component per snapshot) and just have aprops
argument instead of thepropsCombinations
. Other option could be to have a totally different function to render the grid of different combinations and other function to render just one Component.Flagging that I refer to this as rendering a "base state" because for example, for testing user interactions like hover, there we will need to render just one Component, as we can just hover one node at a time.
The Value Add
It would significantly reduce the number of snapshots taken of a component, in addition to allowing exhaustive testing of all the different rendering cases of a component much faster.
Possible Tradeoffs
Knowing the specific combination of props for each cell could be a problem if there is not a very clear visual relationship between the visual impact and the name/values of the prop.
The text was updated successfully, but these errors were encountered: