-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
test: component test updates #19925
test: component test updates #19925
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ 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 |
@@ -42,21 +41,24 @@ describe('<SpecsList />', { keystrokeDelay: 0 }, () => { | |||
acc.relative.length < spec.relative.length ? spec : acc | |||
, specs[0]) | |||
|
|||
cy.get(inputSelector).type('garbage 🗑', { delay: 0 }) | |||
cy.findByLabelText(defaultMessages.specPage.searchPlaceholder) |
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.
No need to answer or change anything here right now, but are we sticking w/ i18n in specs or not? there's a ton of discussion around this, it's not entirely clear what we landed on.
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.
Last I recall we were "sticking with it" as a practice but not to the point where we would hold up a PR that doesn't do it.
cy.findByLabelText(defaultMessages.specPage.searchPlaceholder) | ||
.as('specsListInput') | ||
|
||
cy.get('@specsListInput').type('garbage 🗑', { delay: 0 }) |
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.
Not your change but what does delay: 0
do here? (why do we need 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.
I think it's just cumulatively saving some time across tests (vs the 10ms default)? We do it several places, @JessicaSachs might know if there's a bigger reason.
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.
Reapproved after dismissing @lmiller1990 approval
* 10.0-release: (25 commits) fix(unify): improve dev server config ergonomics (#19957) feat: add spec pattern modal (#19801) fix: Windows e2e project scaffolding issues (#19938) feat: update @cypress/schematic to use proper e2e config for 10.0.0 (#19827) fix: correctly migrate projects with custom integration folder (#19929) fix: component spec creation with spec pattern (#19862) fix: missed committing yarn.lock after merge conflict fix: correct reference branch / commitSha in performance-reporter (#19941) feat: update navbar UI per Figma (#19926) fix: seed examples files when no e2e directory is created (#19768) chore: remove windy lightBlue warning test: component test updates (#19925) feat: Focus browser from select browser screen and on dashboard login (#19842) test: Honeycomb system-test reporter (#19855) fix(deps): update dependency engine.io to v5.2.1 [security] feat: Retain fileName when working with aliased fixtures and files (#19820) Update release-process.md Update release-process.md Update release-process.md Update release-process.md ...
Additional details
In the order GH presents the files, this PR:
alertClass
is confusing and targets the same element as the header, so it wasn't having any effect when used as the tests suggest it should be used.label
but for this PR I sidestepped that and fixed labels in consumers instead. The style of labels varies a lot.PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?