In Recommendation: Cleanup import paths by creating and publishing a mw-selenium-page-objects library and Cleanup import paths by creating and publishing a mw-selenium-page-objects library @Jdlrobson has asked why we don't publish a npm package instead of having shared page objects in core.
|Open||None||T182986 Selenium framework improvements|
|Open||None||T190995 Someday/maybe Selenium framework improvements|
|Resolved||None||T182692 Document differences between Ruby and Node.js Selenium frameworks|
Patch Set 1: Code-Review-1
No no. We agreed to have all the boilerplate at a single place (mediawiki/core) to ease the maintenance. We cant afford to have that code and list of dependencies scattered all in multiple repositories.
If it is too hard to run a specific extensions test or a single spec file, lets enhance the doc in mediawiki/core ( tests/selenium/README ) and eventually add an helper in core ( similar to tests/selenium/selenium.sh ).
I have no opinion on if tests should exclusively run from core or if should make it possible to run them from an extension. I do care about making it consistent. ORES is already set up to run tests from the extension. I have thought you were aware that @Jdlrobson has requested it and that @Krinkle has implemented it, but you might have been busy with other things at the time and missed it.
We started wdio test suite by following the same principle we had for QUnit: have everything in mediawiki/core. @Krinkle did a nice analysis at T193943#4313350 about why it would be better to decentralize: namely that lets extensions upgrade at their own pace and mediawiki/core changes are not going to break the tests.
We have the shared code maintained in mediawiki/core in tests/selenium/wdio-mediawiki. It is a published npm package: wdio-mediawiki. Extensions rely on that npm package instead of the code in core.