As an engineer reviewing KDS pull requests, I would like to see what visual differences resulted from the PR's changes. A visual testing GH workflow should be created that:
executes the visual tests specifically
only runs if components or tests have changed (for instance, it does not run if a PR only changes another GH workflow)
only runs after unit tests have passed (to prevent using Percy credits unnecessarily)
adds a failed PR check when there are visual differences
provides a link to Percy for PR reviewers to either approve or reject the visual differences
resets or re-runs the failed PR check when a reviewer approves the visual differences (if possible)
The existing unit testing workflow should remain unchanged.
Current behavior
No such workflow or functionality currently exists
(Optional) The Value Add
This will help contributors making changes to KDS, and reviewers of those changes, be more confident that there aren't visual regressions caused by the changes.
(Optional) Possible Tradeoffs
It adds another step in the process of PR reviews, but a step that would otherwise be a manual process. Insufficient visual test coverage could also expose weaknesses in the process.
Product
KDS itself
Desired behavior
As an engineer reviewing KDS pull requests, I would like to see what visual differences resulted from the PR's changes. A visual testing GH workflow should be created that:
The existing unit testing workflow should remain unchanged.
Current behavior
No such workflow or functionality currently exists
(Optional) The Value Add
This will help contributors making changes to KDS, and reviewers of those changes, be more confident that there aren't visual regressions caused by the changes.
(Optional) Possible Tradeoffs
It adds another step in the process of PR reviews, but a step that would otherwise be a manual process. Insufficient visual test coverage could also expose weaknesses in the process.