- code review
- Make sure all async patches are as small as possible
|mediawiki/core||master||+20 -13||WIP WDIO(async): Make tests in tests/selenium/specialrecentchanges.js async|
|mediawiki/core||master||+23 -23||WIP WDIO(async): Make tests in tests/selenium/specialwatchlist.js async|
|mediawiki/core||master||+151 -114||WIP WDIO(async): Make tests in tests/selenium/page.js async|
|mediawiki/core||master||+58 -40||WIP WDIO(async): Make tests in tests/selenium/specs/user.js async|
|mediawiki/core||master||+7 -7||WIP WDIO(async): skipping all test suites|
|mediawiki/core||master||+0 -26||WIP WDIO(async): remove wdio-sync npm package|
|Resolved||zeljkofilipin||T247833 Mentor a Google Summer of Code 2020 student|
|Resolved||zeljkofilipin||T247835 Evaluate WebdriverIO replacements for our browser automation framework|
|Open||None||T256626 Investigate WebdriverIO async mode|
In October as part of T234002 and https://gerrit.wikimedia.org/r/539865 I explored using the wdio-async mode but abandoned the idea. From what I can tell, wdio-sync is the only well-understood and supported mode in upstream for wdio. Without it things get quite confusing, fall apart somewhat, and the code doesn't become better, either.
What I did do, is remove all use of browser.call() which was the only publicly exposed usage of Fiber in our code (in favour of native async-await).
This means we no longer use Fiber to weirdly pause execution and wait for our own promises and async code. It is however still used by wdio internally to make browser.goto(), and $() and waitFor and all other wdio commands appear synchronous which is by design and hard to avoid.
Has upstream Wdio decided to make async the default recommended, advertised and documented mode for all examples etc?
@Krinkle after writing the first test in async mode for wdio, I personally that the tests are more elegant when written in the sync mode. The idea was to replicate some syntax sort of similar to that we use for Puppeteer however clearly with async mode, the test lose their readability for wdio which is the opposite to what we aimed for! Maybe I am doing things the wrong way. I'll add you as reviewer, maybe I am doing something the wrong way
Upstream advertises the sync mode and that is how most people use it.
I looked into async mode as I suspected the Fibers layer might be behind the slowness, but it wasn't the root cause (the root cause was badly written MW tests).
What problem are we looking to solve by changing to async mode?
@Krinkle I would say the problem is more towards the cosmetic side of things. We were really impressed with the async-await syntax used by Puppeteer for how clean and legible it is. So we thought it might be a good opportunity to conduct a short PoC. It was a plan to hold a short meeting to discuss regarding the same with you but with the GSoC deadlines to respect it went a little lower in the list of agendas. Would you be willing to set up a short meet with @Zeljko9889 and me possibility sometime next week?
@Krinkle @Soham This was an interesting experiment, inspired by puppeteer async syntax. (See T247843: Evaluate Puppeteer as a WebdriverIO replacement for our browser automation framework and related commits.) I think the conclusion is that webdriverio async is not ready yet. Please correct me if I'm wrong. Also, feel free to reopen the task if you disagree or if there's anything left to do.
I'll abandon commits related to this task.