-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add visual regression coverage #264
Conversation
@@ -0,0 +1,8687 @@ | |||
// Jest Snapshot v1, https://goo.gl/fbAQLP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we use this snapshot file somewhere? if not and it's just auto-generated, maybe we could remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the storyshot add-on renders generates a jest snapshot from stories. It should be committed so it will compare the future renders in pr with the snapshot as part of the testing. The snapshot file needs to be updated by running the storyshot command and committed every time there's an approved change in code implementation, so we might need a github action to do that. More information here: https://jestjs.io/docs/snapshot-testing
It's the one storyshot test that tests all components. The |
When we're collecting the coverage, what files under |
This reverts commit 32746ce.
@@ -1,6 +1,5 @@ | |||
import { useRecentSearches } from '../../src/hooks/useRecentSearches'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(putting the comment here so we can have a comment chain, but asking about storyshot.test.ts.snap) What is storyshot.test.ts.snap?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
storyshot.test.ts.snap is a jest snapshot generated with stories using the storyshot add-on and would be used to compare against future renders of test UI in pr. (https://jestjs.io/docs/snapshot-testing) It needs to be updated by running npm run coverage:visual
and committed if there is an approved change in implementation for the tests to pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to use the Percy snapshots instead of a local one? If not, no worries. But, I think we need to include a GH Action that will make a PR updating the Snapshot when appropriate. Without that action, people will inevitably forget to generate a new Snapshot and check it in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to add actual snapshot testing here? I thought all we wanted was the coverage, we don't need to see if the snapshot has changed.
If we do need this file and DO need it up to date I would rather generate it on the fly instead of checking it into the repo. I'd like to avoid adding additional noise to the repo if possible. By generate on the fly I mean, as part of running the visual coverage, we would first check out the base branch of the PR, generate storyshot.test.ts.snap
, and then checkout the branch with the actual changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also is storyshot.test.ts.snap
the default name for the file? It feels a little wordy
…or base coverage test in combined-test pr
@@ -1,6 +1,5 @@ | |||
import { useRecentSearches } from '../../src/hooks/useRecentSearches'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to use the Percy snapshots instead of a local one? If not, no worries. But, I think we need to include a GH Action that will make a PR updating the Snapshot when appropriate. Without that action, people will inevitably forget to generate a new Snapshot and check it in.
@@ -1,5 +1,5 @@ | |||
import { useSynchronizedRequest } from '../../src/hooks/useSynchronizedRequest'; | |||
import { renderHook } from '@testing-library/react-hooks'; | |||
import { renderHook } from '@testing-library/react-hooks/dom'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked with a couple other Slapshot folks, we weren't able to see this warning. It may be related to your NPM/Node version. I'd rather we avoid using the dom
version of renderHook
if possible. Depending on the dom
version can lead to other, nuanced issues.
I couldn't find anything on coverage report with Percy snapshot, but there is another option codecov which works in github but not locally and supports visual, jest, and merge coverage reports. We would need to sign up for an account with them to use the service. |
package.json
Outdated
"coverage:visual": "jest --projects tests/jest.visual.config.js --coverage", | ||
"coverage:clean": "rm -rf .nyc_output && rm -rf coverage", | ||
"coverage:merge": "istanbul-merge --out coverage/merged/coverage-final.json ./coverage/unit/coverage-final.json ./coverage/visual-regression/coverage-final.json", | ||
"coverage:merge-report": "nyc report --reporter=lcov --reporter=text --temp-dir=./coverage/merged --report-dir=./coverage/merged", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my edification what is coverage:merge-report doing? Which lcov files is it merging together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
merge-report is only displaying the coverage on screen with the merge json file generated with the merge command
I think Codecov does basically the same thing as Coveralls. The reason we ended up choosing Coveralls over Codecov was a security breach that happened a little bit before we started looking at cloud coverage providers https://blog.gitguardian.com/codecov-supply-chain-breach/ |
After digging into visual regression coverage test approaches with Julianne, looks like storybook is moving away from storyshots and to @storybook/test-runner with a code coverage generation option. This requires less setup compare to storyshot (no snapshots needed). We made another PR here: #275 |
Add a GH workflow to check for WCAG violations. If the check fails, the PR will be blocked from merging into main. There are some WCAG violations that we ignore, namely color contrast failures on stories where components are in a "loading" state. Using config options, that rule is disabled for those particular stories. To get the automated WCAG checks, Storybook has to be running while the `npm run wcag` command is run. Note, Jest had to be downgraded to v27 to work with `@storybook/test-runner`. But, it looks like they will be adding support for v28 shortly (storybookjs/test-runner#154), so we should be able to upgrade again soon. In the meantime, we haven't been using any features from v28, so the downgrade didn't affect any tests. Also, the Snyk checks are failing, but the new license and one of new vulnerabilities are both approved by legal in Juliann's [PR](#264 (comment)). The other new vulnerability is also introduced only through Storybook, so we wouldn't be susceptible to it. J=SLAP-2289 TEST=auto See that the check runs as expected on this PR and passes.
Add a GH workflow to check for WCAG violations. If the check fails, the PR will be blocked from merging into main. There are some WCAG violations that we ignore, namely color contrast failures on stories where components are in a "loading" state. Using config options, that rule is disabled for those particular stories. To get the automated WCAG checks, Storybook has to be running while the `npm run wcag` command is run. Note, Jest had to be downgraded to v27 to work with `@storybook/test-runner`. But, it looks like they will be adding support for v28 shortly (storybookjs/test-runner#154), so we should be able to upgrade again soon. In the meantime, we haven't been using any features from v28, so the downgrade didn't affect any tests. Also, the Snyk checks are failing, but the new license and one of new vulnerabilities are both approved by legal in Juliann's [PR](#264 (comment)). The other new vulnerability is also introduced only through Storybook, so we wouldn't be susceptible to it. J=SLAP-2289 TEST=auto See that the check runs as expected on this PR and passes.
This PR adds visual regression coverage tests by using add-on storyshot from storybook. Storyshot renders a test UI with jest upon testing and compares the previously generated jest snapshot from stories with the render.
SLAP=J-2269
TEST=manual
Tests were able to run after executing the following command to show visual regression
npm run coverage:visual
for visual-regression coverageSnyk issues: approved by legal