[Visual Testing]: Optimize the amount of snapshots taken by component

[AlexVelezLl]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

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:

await renderComponent('KButton', {
  propsCombinations: {
    text: ['Test Button'],
    appearance: ['raised-button', 'flat-button', 'basic-link'],
    primary: [true, false],
    disabled: [false, true],
    icon: ['', 'add'],
    iconAfter: ['', 'video'],
  },
  gridItems: {
    layout12: { span: 3 },
  }
});

And render all the different combinations of propsCombinations in a single grid, and use the gridItems 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 a props argument instead of the propsCombinations. 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.

[Pandaa007]

Hi! Is this issue open for contribution? I can help to create a small proof of concept PR that can be used by the team to further ideate and document any possible hiccups if that's helpful.

[AlexVelezLl]

Hey @Pandaa007! Thanks for your interest in taking this up! For now, we want to experiment with the current workflow of single snapshots first to have a sense of how the process works just with it :), and then we will be able to make the decision if we want to continue with this. For now this issue is just a place to put the ideas we had in case we need it 👐.

[MisRob]

Related to https://github.com/learningequality/kolibri-design-system/issues/1059