We use the EditPage from the core node selenium tests in the Revision-Slider and Two-Column-Edit-Conflict-Merge extensions and it really would be more convenient to have it available as part of wdio-mediawiki for both of them.
Description
Description
Event Timeline
Comment Actions
For Revision-Slider see [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/RevisionSlider/+/499855/6/tests/selenium/pageobjects/diff.page.js | RevisionSlider/+/499855/6/tests/selenium/pageobjects/diff.page.js ]].
For Two-Column-Edit-Conflict-Merge see [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TwoColConflict/+/master/tests/selenium/pageobjects/editconflict.page.js | TwoColConflict/+/master/tests/selenium/pageobjects/editconflict.page.js ]].
I think it would be better to add the functionality to Api.edit() than to use EditPage. @Krinkle, what do you think?
Comment Actions
At least for Two-Column-Edit-Conflict-Merge I need to do a "real manual" edit with the edit page to trigger the edit conflict. So using the API does not really help here ;-).
Comment Actions
Indeed. The UI page object from core should not be exposed in the wdio package. If the extension just needs to make an edit, it should use the API. If it needs to use the UI because it is testing its own code, then it should also own the Page subclass itself.
Comment Actions
Yep, that's a good use of UI page objects. But also a case where you want to own the Page object locally and query the elements as needed based on the changes the extension has made to it.
Comment Actions
@WMDE-Fisch @Krinkle looks like the decision is to use the API for edits that don't need the UI. If an extension needs to edit a page via the UI, then the extension has to have it's own EditPage? Correct? Can this task be resolved then?