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
LF-4026 Get Cypress tests passing on current state of integration #3100
LF-4026 Get Cypress tests passing on current state of integration #3100
Conversation
…n-current-state-of-integration
No longer searchable like this since PR #2951
Also change assertion on Proceed button click which was flaky locally
…current-state-of-integration
Also gitignore coverage report directory
Test was suddenly failing at this step
… order All of CheckTaskNavigation is included within CreateCleanTask
… of date wait call Not sure what @markerJsRequest used to wait, but tests now fail at that point
Also add three skipped selectors
…tax and remove hardcoded wait
…nds.js regular functions
cy.get(Selectors.ADD_TASK_LOCATION_CONTINUE).should('exist').and('not.be.disabled').click(); | ||
|
||
// This screen only present when this test file is run after crops.js | ||
cy.get(Selectors.ADD_TASK_CROPS_CONTINUE).should('exist').and('not.be.disabled').click(); |
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.
This is the cause of the temporal dependency between crops.js
and tasks.js
. There is an additional page in this multi-page form when a crop plan exists on the farm.
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.
In the future to make this more robust and ensure the tests are independent, we'll likely need to bake in the creation of a crop in the tasks test itself as a part of the test setup before assertions. We'll probably end up abstracting the code that does the crop creation on its own reusable command
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.
Ah that's a good idea! I was thinking the spec needed to be more flexible here, but instead the environment could have been made more predictable.
|
||
cy.get('[data-cy=addTask-cropsContinue]').should('exist').and('not.be.disabled').click(); | ||
// This screen only present when this test file is run after crops.js | ||
cy.get(Selectors.ADD_TASK_CROPS_CONTINUE).should('exist').and('not.be.disabled').click(); |
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.
As above
I think you are still working on this... but I took a look early -- I have seen it has passed CI ! Nice! My main question will be about the movement/deletion of the google maps intercept requests any extra info you can provide would be cool. |
…eforeEach setup
@@ -0,0 +1,45 @@ | |||
/* |
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.
What got timeboxed here was writing this function in ts and accepting an array instead of a single additional file -- after wrangling with the cy.fixture()
promises for a while I left it be. It would be good for those improvements to be made someday 🙂
@Duncan-Brain hmmm I don't know if I have too much extra info there! Mostly it's the exact same as how Mika set it up and I've come to love the pattern. I think the only things I changed were:
|
This was a point of failure in 2nd CI run
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.
This is really great work! 🙌 we might need to figure out a way to get rid of the explicit waiting at some point if it ends up in flakiness, but for now we move on 🙂 (relatedly, I found this article that I really enjoyed about cy.wait https://filiphric.com/waiting-in-cypress-and-how-to-avoid-it)
@@ -0,0 +1 @@ | |||
.nyc_output |
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 this related to code coverage? We're not running any coverage reports right now, right?
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 exactly! And running the tests locally regenerates this folder, with the contents a single JSON file containing this 😆
{}
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.
Thanks @kathyavini for the explaining those little changes!
Might be worth asking Mika about the marker thing or others for the future..... I agree I cant find any use of it in our frontend.
TODO:
Description
This is an update of PR #2931, addressing comments in that PR and getting the tests passing on the current state of integration by updating selectors and points of failure/flakiness. It has been running smoothly locally, no flakiness, for several days now so hopefully the same on GitHub!! 🤞
Notes on running locally within
packages/end-to-end
withnpm run cypress
:crops
test needs to be run before thetasks
test. This will always be the case in CI (they are run sequentially) but I'll make a note in the code because eventually it would be much better if the specs could be run in total isolationJira link: https://lite-farm.atlassian.net/browse/LF-4026
Type of change
How Has This Been Tested?
Run locally from within
packages/end-to/end
with refreshed database usingnpm run cypress
Checklist: