test: make content consistent in component tests that use faker #23080
Conversation
|
Thanks for taking the time to open a PR!
|
| @@ -135,11 +137,11 @@ describe('<Collapsible />', { viewportHeight: 450, viewportWidth: 350 }, () => { | |||
|
|
|||
| const target = ({ open }) => (<h1 class={['text-xl', { 'pb-2': open }]}>Click here to open</h1>) | |||
|
|
|||
| cy.mount(() => (<div class="mx-auto text-center w-300px my-4 border-1 p-4 rounded"> | |||
| cy.mount(() => (<div class="rounded mx-auto border-1 my-4 text-center p-4 w-300px"> | |||
There was a problem hiding this comment.
No changes here, just class order getting updated on save.
|
Test summary
Run details
View run in Cypress Dashboard ➡️ Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
||||||||||||||||||||||||||||||||||||||||||||||
| @@ -6,6 +6,8 @@ import faker from 'faker' | |||
| import { ref } from 'vue' | |||
| const fileMatchButtonSelector = '[data-cy=file-match-button]' | |||
|
|
|||
| faker.seed(1) | |||
There was a problem hiding this comment.
is it worth even using a faker module vs just removing the dependency and hard-coding a string? 🤔
There was a problem hiding this comment.
I'd argue it's worth keeping it. I actually like the signal that "this is truly meaningless data, we only care that we get back what we put in" as opposed to a string that should be matched because the component is doing some calculations or something, where it's meaningful that the specific expected string is there.
But we aren't systematic in that kind of usage, so sure, it wouldn't be bad to talk about more.
User facing changelog
N/A
Additional details
The content generated by faker was causing some visual regression failures as it changed in each test run. This PR adds a faker seed so that we now use consistent data when faker is called.
Steps to test
Load up the
FileRowspec in the Launchpad project, rerun it a couple of times and you should see the same data each time. Comment out thefaker.seed(1)and you should see that the data then changes each time you re-run the spec.There are lots of other places we use faker, so I added the seed there as well, even though they are not currently covered by Percy snapshots that are flaky.
Being able to easily grab fake data when writing tests and have it change still seems very useful when developing components, so I'm not suggesting removing faker at this point -- but in CI I think we are going to be happier with stable values.
How has the user experience changed?
N/A
PR Tasks
cypress-documentation?type definitions?