Last modified: 2014-02-12 23:54:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T38007, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36007 - Unit test issues
Unit test issues
Status: RESOLVED FIXED
Product: MobileFrontend
Classification: Unclassified
stable (Other open bugs)
unspecified
All All
: Low normal
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-16 10:22 UTC by Krinkle
Modified: 2014-02-12 23:54 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2012-04-16 10:22:41 UTC
In no particular order:

* tests/js/fixtures.js and javascripts/application.js are loaded twice. Especially noticeable in debug mode. Please remove the redundant or use a utility module that both depend on instead of including the same file twice in two different modules. 

* fixtures.js is executing DOM functions without waiting for document ready, this can be a problem.

* If none of the MF tests are run (e.g. ?filter=jquery.colorUtil), then there should be no DOM manipulations or global variables/functions defined by MF unit test code. Schedule dom manipulation in teardown/setup functions, that way they are automatically reset after each test (so that they don't affect each other), and it also ensures none of them are ran if the tests aren't ran. Right now it creates the fixtures also if none of the tests are scheduled to run.

 And in debug mode it creates global variables MFE and MFET in some of the test files, these should be local to the suite, maybe use a closure for them like
( function ($, mw, MFConf, MFE, MFET) {
 /* .. */
}(jQuery, mediaWiki, mwMobileFrontendConfig, MobileFrontend, MobileFrontendTests));

.. Or, after porting to ResourceLoader, have them all under mw.*, where mw.conf and mw.messages are automatically reset after each test if you use (or build on) QUnit.newMwEnvironment().

* the "qunit-fixture-x" element is non-standard pollution of the document on Special:JavaScriptTest/qunit and isn't hidden by default. This causes it to be unconditionally and infinitely visible in plain sight on that page when only other test suites are ran (e.g. when setting ?filter=jquery.byteLength, the whole MobileFrontend fixture remains in plain sight.)

QUnit has build in fixture teardown/setup after each test, using the contents of <div id="qunit-fixture"> at time of the first test as base and resets it to that after each test. Use the QUnit "begin" (`QUnit.begin(fn callback)`) hook to add something to this (do not set innerHTML as that would break other test suites fixture code, instead append to it from the test initiator via the QUnit.begin() hook).

* This goes deeper into MobileFrontend's bigger issues, but it's using awfully generic names and titles all in the main namespace. Such as:
- global function `wm_toggle_section`
- DIV id="logo", "nav", "sq", "search", "anchor_1", "section_1"

* Assertions: The tests for addClass and removeClass should not be using hasClass for verification. Especially for the tests where it creates a new element and adds one class, it is more reliable to check the raw className property for equality instead. The hasClass assertions, similarly, should use className directly (or just as part of the '<div ..></div>' snippet) to create the test and then use hasClass to test it, right now it is mixing too much leaving a fair chance of missing failures if something is wrong with either one of them.
Comment 1 Mark A. Hershberger 2012-04-17 16:58:18 UTC
This should really be turned into a tracking bug for each of these separate issues.
Comment 2 Jon 2012-04-19 12:41:26 UTC
Agreed with all the above although not too sure about not using jQuery's hasClass for testing.. seems overkill... as the rest of the tests already assume jquery is fine. I have a hasClass function in application.js but this is different.

When I first rewrote MobileFrontend I had to write unit tests to test existing content which had lots of globals so some of the tests are not written how I'd like them. I think it's safer now to address the problems above you describe.
Comment 3 Krinkle 2012-04-23 10:34:14 UTC
(In reply to comment #2)
> Agreed with all the above although not too sure about not using jQuery's
> hasClass for testing.. seems overkill... as the rest of the tests already
> assume jquery is fine. I have a hasClass function in application.js but this is
> different.
> 
> When I first rewrote MobileFrontend I had to write unit tests to test existing
> content which had lots of globals so some of the tests are not written how I'd
> like them. I think it's safer now to address the problems above you describe.

Assuming jQuery is fine is okay. I was referring to the hasClass function that is implemented as MobileFrontend.utilities.hasClass (not jQuery hasClass). In that one method of a library should not be used to test another and visa vera.

But I see now that the test isn't using MF's own hasClass, but jQuery's hasClass, so that's fine. But I also noticed that MF's own hasClass doesn't have tests right now, but coverage is not a blocking issue, that'll get better over time.

And besides, depending on how the ResourceLoader integration progresses, most of this part part of the MF library may become obsolete.
Comment 4 Jon 2012-05-01 12:36:09 UTC
I think this is all taken care of except for the MobileFrontend "using awfully generic names and titles all in the main namespace" which I've opened as a new bug 36379

I believe I've covered most of your issues. Please create a new bug ticket if there are still any outstanding problems.

remote: New Changes:
remote:   https://gerrit.wikimedia.org/r/6232
remote:   https://gerrit.wikimedia.org/r/6233
remote:   https://gerrit.wikimedia.org/r/6234
remote:   https://gerrit.wikimedia.org/r/6235
remote:   https://gerrit.wikimedia.org/r/6236
remote:   https://gerrit.wikimedia.org/r/6237
remote:   https://gerrit.wikimedia.org/r/6238

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links