Skip to content
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

chore(e2e-development): bump cypress version #28580

Merged
merged 9 commits into from
Dec 11, 2020
Merged

Conversation

pieh
Copy link
Contributor

@pieh pieh commented Dec 11, 2020

Description

I had to skip adding e2e tests for loading indicator in #28562 because we use old version of cypress that doesn't seem to have shadow dom support, newer ones seem to have - so let's see how this will go.

There some additional niceties here, like auto-retry (will see how that goes). I also added some cleanup after some of tests because running tests does leave mess behind and we need to clean that mess up manually if we want to rerun tests (when iterating on it).

Also ... some query data caches had .only on one of tests (yikes), luckily we didn't mess with runtime in that would affect it (I think), but just unskipping rest of tests too

@gatsbot gatsbot bot added the status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer label Dec 11, 2020
@@ -110,7 +110,7 @@ describe(`navigation`, () => {

describe(`Supports unicode characters in urls`, () => {
it(`Can navigate directly`, () => {
cy.visit(`/안녕`).waitForRouteChange()
cy.visit(encodeURI(`/안녕`)).waitForRouteChange()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chrome actually make encoded request - it's just ui nicety that it keeps unicode characters - this is needed for Cypress 3.5.0+ to work - otherwise we get "Could not load page" error from cypress (not even from our runtime / server)

Screenshot 2020-12-11 at 02 46 16

@@ -356,7 +356,7 @@ describe(`Keeping caches up-to-date when updating data`, () => {

describe(`Keeping caches up to date when modifying list of static query hashes assigned to a template`, () => {
describe(`using gatsby-link`, () => {
it.only(`Navigate from page A to page B, add static query to page A, navigate back to page A`, () => {
it(`Navigate from page A to page B, add static query to page A, navigate back to page A`, () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ops :(

cy.get(`li`)
.its(`length`)
.should(`be`, count + 1)
cy.get(`#fake-data li`).should(`have.length`, count + 1)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was acting weirdly - for once - it would resolve .get as quickly as it wound find any li - and also it would not allow should('be', foo) to be actual assertion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was also all wrong because there is double the amount of li on the page because #pinc-data is also on the same page - this was all weird and certainly this test wasn't actually asserting correctly (it was passing by accident or something)

webhookBody.items.forEach(node => createNode(api.getNode(node, helpers)))
webhookBody.items.forEach(node =>
createNode(api.addNode(api.getNode(node, helpers)))
)
Copy link
Contributor Author

@pieh pieh Dec 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

api wasn't tracking this, so resetting was never removing node create through explicit webhookBody.items way. This meant that gatsby-preview/updating.js and gatsby-preview/refreshing.js only kind of worked when they were running in ... alphabetical order - if you would run them manually with cy:open in different order - those would fail (wat)

it also mean that to rerun those tests you would ... have to restart whole gatsby develop 😱

I also need to mention here that fact that the node is not automatically cleaned up is weird - but this was like that since gatsby@2 (and likely earlier). So this need to be addressed - but it needs new APIs and is possibly breaking change - so I don't consider this a bug and rather a quirk ... (well it might be considered as bug - but it's how it works and changing it now would break whole lot of things than rely on this behaviour)

@pieh pieh added type: maintenance An issue or pull request describing a change that isn't a bug, feature or documentation change and removed status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer labels Dec 11, 2020
@pieh pieh marked this pull request as ready for review December 11, 2020 02:47
pvdz
pvdz previously approved these changes Dec 11, 2020
Copy link
Contributor

@pvdz pvdz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@pieh pieh merged commit b8dec9a into master Dec 11, 2020
@pieh pieh deleted the bump-cypress-version branch December 11, 2020 11:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: maintenance An issue or pull request describing a change that isn't a bug, feature or documentation change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants