-
Notifications
You must be signed in to change notification settings - Fork 15
Upgrade WebdriverIO to v9.20.0 #1770
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Yuyutsu Rai <Yuyutsu.Rai@ons.gov.uk>
… for more robust testing
…tly used in webdriverv8 Signed-off-by: Yuyutsu Rai <Yuyutsu.Rai@ons.gov.uk>
Signed-off-by: Yuyutsu Rai <Yuyutsu.Rai@ons.gov.uk>
…on and interestital spec
…plemenetary data tests are executing before page is rendered Signed-off-by: Yuyutsu Rai <Yuyutsu.Rai@ons.gov.uk>
berroar
left a comment
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.
Was just wondering with:
Some tests became flaky due to reliance onbrowser.pause() to avoid race conditions. Therefore a new helper function has been added, waitForPageToLoad(), which waits for the page to fully load.
Did we test without replacing these at all? I think they were initially added before we went back to running consecutively?
Tested on a seperate branch and works without browser.pause. Changes have now been added to this branch 👍 |
berroar
left a comment
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.
Observing a lot of The data in this module is over two months old. To ensure accurate Baseline data, please update: npm i baseline-browser-mapping@latest -D` in the run logs.
Transitive package from: I have upgraded the dependencies in babel so now Update: new version of basline-browser-mapping has been released and resolves the issue. |
| // directory is where your package.json resides, so `wdio` will be called from there. | ||
| // | ||
| specs: ["./spec/**/*.js"], | ||
| specs, |
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.
We now define Specs at the top, depedning on what the MODE variable equals too. So we can sepearte the SDS Specs (flakey) from the rest of the Specs
| booleanFlag, | ||
| }); | ||
| this.url(`/session?token=${token}`); | ||
| await this.url(`/session?token=${encodeURIComponent(token)}`); |
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.
await to prevent any race conditions - flakiness
encodeURIcomponent for an added layer of security
| npm run test_functional_main | ||
|
|
||
| test-functional-sds: generate-pages | ||
| EQ_FUNCTIONAL_TEST_MAX_INSTANCES=1 npm run test_functional_sds |
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.
Flakiness was persisting when Instances was higher than 1
|
Just added a few comments explaining reasons for certain changes |
liamtoozer
left a comment
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.
Changes look great and just wanted to call out great PR description as well 👍
I think this is more to do with the bump to wdio v9, but I wonder if some of the new flakiness we're seeing more of in Actions now is because of this. I think we might need to spend a bit of extra time to prevent introducing extra flakiness for some of these tests, because I'm seeing a few different failures that weren't cropping up as often with v8. Appreciate that you're trying to tackle this already though 👍 Not sure what the solution is yet but we might need to park this and spawn off an investigation into some of the newer intermittent failures?
Also, just a very minor suggestion, I think we might benefit from calling getHTML() from inside a central wrapper/helper function, and defaulting with the { prettify: false } object there instead. Otherwise, passing the object in multiple place might be a maintenance overhead if we need to refactor in future? Might help keep some of the assertions to look a bit cleaner?
| beforeEach(async () => { | ||
| await browser.openQuestionnaire("test_mutually_exclusive.json"); | ||
| await browser.pause(100); | ||
|
|
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.
Very, very (very) minor: Not sure if the linter might have done this, but there are now blank lines where the previous browser.pause() was? I think there are a few files like this that might need to be updated too
| }); | ||
|
|
||
| it("Given I start a survey, When I view the introduction page, Then I should be able to see introduction information", async () => { | ||
| await browser.openQuestionnaire(introductionSchema); |
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.
Good spot with these redundant calls 👀
What is the context of this PR?
This PR upgrades all WDIO packages to
v9.20.0and updates our functional tests to comply with the new upgrades.Changes made
getHTML()no longer takes a boolean flag. It now accepts an options object. The default options:({ includeSelectorTag: true, prettify: true })were causing differences in the returned HTML, which led to assertion failures (formatting changes and missing alt attributes on logo tags). We have to explicitly set these values to false.newWindow()now needs to explicitly have a URL value. In v8,newWindow()implicitly openedabout:blankwhen no URL was provided. In v9 this implicit default was removed, so we now explicitly pass 'about:blank' when opening a new window.SDS Tests in GA are failing when in the main test, but work when separated into their own job with "MAX_INSTANCE=1". Also the very first SDS launch always hits the “Sorry, there is a problem with this service” page. So a new helper function -
openQuestionnaireWithRetry(). I think we need an investigation on why SDS is failing like this in GA only.Chrome options also updated in an attempt to make tests more consistent.
Babel dependencies have also been upgraded to latest versions
How to review
Links
Checklist