Page MenuHomePhabricator

MobileFrontend QUnit tests are broken in Special:JavaScriptTest
Closed, ResolvedPublic

Description

Steps to reproduce:

  • set up MediaWiki via Vagrant, with the mobilefrontend role
  • visit Special:JavaScriptTest in Chrome

All of the MobileFrontend tests are broken:

  • MobileFrontend NearbyGateway.js: _distanceMessage() tests mostly fail on expectation about what the gateway returns (presumably there is some request/response mocking that's not working as expected)
  • lots of t.stub(...).callsFake is not a function (different version of sinon.js being used?)
  • lots of Cannot read property 'then' of undefined
  • lots of TypeError: t is not a constructor
  • lots of TypeError: Cannot read property 'prototype' of undefined
  • a bunch of othe TypeError: Cannot read property 'XXX' of undefined
  • a couple more assertion failures

Event Timeline

Possibly some (but not all) is from T253993: mediawiki.ForeignApi QUnit tests are broken in Special:JavaScriptTest which seems to cause a number of unrelated tests to fail.

Change 599891 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Restore QUnit JSTest compatibility

https://gerrit.wikimedia.org/r/599891

Jdlrobson subscribed.

MobileFrontend uses a more modern version of sinon which it's not shipping in that bundle. The above config change fixes it.

On top of that there were a few stubs missing.

@Tgr any chance of a review?

Note: you'll need to run npm run build to generate the tests. This needs to be run on every update.

Jdlrobson triaged this task as Medium priority.
Jdlrobson moved this task from Incoming to Needs Prioritization on the Web-Team-Backlog board.

Thanks for the super quick fix! Properly doing the build step fixes about 20 tests (filed T254023: MobileFrontend repo needs npm build step after code update in MediaWiki-Vagrant about that), the patch fixes 50-ish more. Only one error remains:

MobileFrontend mobile.startup/OverlayManager: #getSingleton (hash present and overlay not managed)
If a page is loaded with a hash fragment a new entry is placed before it to allow the user to go back.
Expected: 	true
Result: 	false

It passes in isolation, but only when started with an URL with no hash fragment. So probably some other test lets state bleed into the hash fragment, and this one doesn't start from a fixture.

Change 599891 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Restore QUnit JSTest compatibility

https://gerrit.wikimedia.org/r/599891

@Tgr yeh the hash fragment one is a bit problematic. I'm not 100% sure what to do with that.

Jdlrobson closed this task as Resolved.EditedSep 3 2020, 9:31 PM

These tests no longer run in Special:JavaScriptTest (see I1b64c88f7037c581552e708adba93022407eed4d, 5418d764cbca590a35831d177ffc799eaa21c65c)