VRT in Figma mobile & desktop libraries

[yceballost]

We will include VRT in new tasks that include layers hidden. For old implementations we are going to think which cases are relevant to apply VRT.

VRT List for old use

• [ ] example

Discussed in https://github.com/Telefonica/mistica-design/discussions/1309

^{Originally posted by aweell June 13, 2023}

Goal

Add test scenarios for visual regression in the libraries that check all the visually hidden properties by default or different configurations of the components so is easier in the review merge of a branch to detect unexpected changes.

Context

The current setup only allows the reviewers of a branch to detect changes in the default configuration of the components and sometimes is complicated to detect the entire impact of a change in a library.

Impact

The test scenarios will allow to detect and solve problems in the libraries before merging to the main branch.

Discussion Questions

• Should all the components with boolean properties have a test?
• Should all the tests live in the same page?

Additional considerations

https://honzatmn.substack.com/p/visual-regression-testing-for-design

Do you have a visual proposal?

No response

[aweell]

Example extracted from https://www.figma.com/community/file/1311421011482282592

[yceballost]

Approach

Figma side

Each component page will have a section called "VRT" to limit the VRT area and differenciate from the real components Inside VRT section we will have N numbers of artboards with the config that want to be tested Each artboard have to follow the following nomenclature: VRT - Component Name - TestDescription

Pe: VRT - Data Card - Aspect ratio 1:1

Github side

Production sync with main branch in Figma

We need to upload to the production branch a folder with all of the screenshots generated. This folder will be in the root and it's called __screenshot_tests__

With webhook v2 from Figma API we can update production screenshot_test folder when changes are applied in the main branch with FILE_UPDATE method. (Triggers within 30 minutes of editing inactivity in a file.)

[!NOTE] Maybe is not the best thing update automatically screenshot in production branch in Github, but I think that is the best way to keep up to date as possible.

Another possible way is to update screenshots in production branch in GitHub when we publish the library.

Compare screenshots

Some options:

1. An option is to generate a PR for each branch with issue nomenclature by default, but maybe we are going to have too much branches generated in Github.
2. Trigger actions manually with the branch id. (More manual step, but we choose what branch need to be compare)
3. Trigger PR with a comment in Figma. (For example, if we comment "test" in the file, the action run)

The PR is cool because we can use cr-extension to see the pixel differences between screenshots. I suppose that could be possible generate the screenshots in the action but we need to find the way to generate screenshots with the pixel differences embedded (I don't really know how to do this xD)

An example of a POC https://github.com/Telefonica/mistica-design/pull/1926

[aweell]

Strategy for VRT

Frequency

The frequency of screenshot generation can be by release

For example, if i release 18.1.0, the baseline for new screenshots will we the published version of the components, and shouldn't change until a new version of the library is publish.

When a new version is going to be published, before publishing libraries, the screenshots should be reviewed and merged and then the libraries can be published.

Ideally, the libraries could be automatically published when the PR of the screenshots is accepted and merged, but this only if its possible.

Examples

In order to avoid high maintenance cost for VRT artboards the example should be reduced as much as possible.

• Have a default version and a content edited version of the component, the content should override all overrideable properties of the component that accept content (text elements, images, icons, slots....etc)
• Only add variants with highest analytics usage in vrt, in order to avoid components with high number of variants to be all in the VRT artboard, booleans can be all tested in same component.