|mediawiki/extensions/Wikibase||master||+1 -1||Skip browser test checking edit links on old revisions|
I assume this is caused by the ItemPage.goToPreviousRevision() function, which as far as I can tell is only used by this one test, and looks extremely fragile. Here’s what it does:
- click on the recent changes link in the sidebar
- click on the “history” link of the last change in the wiki
- click on the date link of the change marked as “after” (this class is assigned based on the two diff selection radio buttons – initially, “before” is the current revision and “after” its parent)
I’m not sure what part of this breaks, but since we already know the item ID, at least the first two steps seem unnecessary to me, and for the last step it might also be better to make an API call to get the second-latest revision.
Agree with @Lucas_Werkmeister_WMDE in that the test could needs some love.
The ItemPage.editItemDescription() is definitely still part of the arrange phase so it could be done via the API just as well (=> second API call, changing the label, creating a second revision), the revision id which is the result of the initial WikibaseApi.createItem() (=> make a sister method which does not reduce this to the itemId), is a what we actually want to know when doing ItemPage.goToPreviousRevision() - once we have them we could use it to open the item page with it (=> mend ItemPage.open()/EntityPage.open() to accept a revision parameter; requires mending Special:EntityPage to also pass on the revision parameter: T232629).
What this test tries is actually quite simple, it gets tricky because the existing methods (e.g. WikibaseApi.createItem()) are so helpful that they do away with key information (which arguably makes sense most of the time).