User:NeilK/UploadWizardTestPlan

Not a plan for executing tests, this is my plan for what tests I'm going to write.

TLDR, high priority classes are:

high

 * mw.ApiUploadFormDataHandler.js
 * mw.ApiUploadHandler.js
 * mw.FormDataTransport.js
 * mw.IframeTransport.js
 * mw.UploadWizard.js
 * mw.UploadWizardLicenseInput.js
 * mw.UploadWizardUpload.js
 * mw.UploadWizardUploadInterface.js

medium

 * jquery/jquery.pubsub.js (maybe never if c68835 lands)
 * mw.DestinationChecker.js
 * mw.GroupProgressBar.js
 * mw.LanguageUpWiz.js
 * mw.UploadWizardDeed.js
 * mw.UploadWizardDescription.js
 * mw.UploadWizardDetails.js

low

 * ext.UploadWizardEvent.js
 * jquery/jquery.morphCrossfade.js
 * jquery/jquery.mwCoolCats.js
 * jquery/jquery.removeCtrl.js
 * jquery/jquery.showThumbCtrl.js
 * jquery/jquery.validate.wmCommonsBlacklist.js
 * mw.canvas.js
 * mw.ConfirmCloseWindow.js
 * mw.ErrorDialog.js
 * mw.fileApi.js
 * mw.FlickrChecker.js
 * mw.units.js
 * mw.UploadWizardInterface.js
 * mw.UploadWizardPage.js

File by file
1) ./ext.UploadWizardEvent.js	Priority: low Appears to fit in with the mw.eventLog system. Seems too trivial to test

non-injectable dependencies: window.location.href mw.eventLog

Unit testable:

Scenario testable: - replace mw.eventLog, create events, check if dispatch works

2) ./jquery/jquery.morphCrossfade.js	Priority: low

non-injectable dependencies: none

Unit testable? - #qunit-fixture - $.morphCrossfader($el); - check that all children have same position - check that 1st child is visible - height of $el matches height of 1st child - $el.morphCrossfade( $elSecondChild, speed ); - 1st child no longer visible - 2nd child is visible - height of $el matches height of 2nd child

Scenario testable: - not needed

3) ./jquery/jquery.mwCoolCats.js	Priority: low (and likely to be replaced anyway) Non-injectable dependencies     mw.Title, mw.api.category, $.fn.removeCtrl

Injectable dependencies mw.Api (argument)

Unit testable: - insertCat - getCats - removeAllCats - getWikiText - #qunit-fixture - the original behavior is user-interactable only - add stuff to input; that's all. - press the 'add another category' link to add another input - add that input - test getCats - getting categories by prefix (with mocked api)

Scenario testable: (this may be done already by browser tests?) - entering data into the form field - checking if category is in wikitext

4) ./jquery/jquery.pubsub.js	Priority: medium

Unit testable: - totally, it uses jQuery as a namespace but doesn't touch the dom - publish, subscribe, unsubscribe - publishReady and subscribeReady, even out of order - purgeReadyEvents - purgeSubscriptions

Scenario testable: n/a

5) ./jquery/jquery.removeCtrl.js	Priority: low

Unit testable: - #qunit-fixture - create one with tooltipsMsgKey and a callback - verify callback fired on click event

Scenario testable: n/a

6) ./jquery/jquery.showThumbCtrl.js	Priority: low

Unit testable: - #qunit fixture - similar to showThumbCtrl, only with different classnames

Scenario testable:

7) ./jquery/jquery.validate.wmCommonsBlacklist.js	Priority: low

Non-injectable dependencies: jquery validate, particularly $.validator.addMethod

Unit testable: - #qunit fixture - could be added to an input created with appropriate contents. Form must already be governed by jquery.validate. - could be rewritten so that the tester was not in a closure, and thus, could be tested :)

Scenario testable: n/a

8) ./mw.ApiUploadFormDataHandler.js Priority: high this is a workhorse - it's used in modern browsers to pull data from the form, and   upload. If chunked is available, will use that   basically takes over a form, gets the configureEditToken on submit if needed, and creates     an appropriate formdata transport object to be triggered on upload    also "publishes" certain facts about us, such as our progress and our general status to the UI

Non-injectable dependencies: mw.FormDataTransport

Injectable dependencies: UploadWizardUpload (with configured .ui and .ui.form), mw.Api

Unit testable: possibly, if we can mock out UploadWizardUpload, and the UI, and the API

Scenario testable: if we use an appriate mw.UploadWizard.config, we can force its use, then do a standard upload

9) ./mw.ApiUploadHandler.js	Priority: high

Manages the form when we are using the iFrame transport method Very similar to ApiUploadFormDataHandler.js

Unit testable: whatever ApiUploadFormDataHandler is	Scenario testable: whatever ApiUploadFormDataHandler is

10) ./mw.canvas.js	Priority: low Just tests for the existence of canvas

Unit testable: yes, ish. has a single method and it's browser specific. We'd have to test browsers with known support or something, but that's basically defined by the library itself.

Scenario testable:

11) ./mw.ConfirmCloseWindow.js	Priority: low Adds an onbeforeunload handler, preserving existing handlers.

Non-injectable dependencies: window

Unit testable: ?? not without closing the window, which qUnit wouldn't like

Scenario testable: perhaps, would need Se, create a page, then try to close it

12) ./mw.DestinationChecker.js	Priority: medium Attaches to an input, checks for uniqueness via api

Unit testable: yes, create such a text input and fire fake events. Can use a mock Api, and even a mock input.

Scenario testable:

13) ./mw.ErrorDialog.js	Priority: low For collecting user feedback. Why is it called ErrorDialog then?

Unit testable: not really

Scenario testable: yes

14) ./mw.fileApi.js	Priority: low Tests browser if various aspects of the File API are available.  Also tests if certain Files have certain characteristics

Unit testable: browser-specific stuff - no   some file stuff -- yes, with data urls? Would have to be very small videos or images

Scenario testable: possibly needed if we can't do files in data urls

15) ./mw.Firefogg.js	Priority: very low It seems few people are using this, although it still works

Unit testable:

Scenario testable:

16) ./mw.FirefoggHandler.js	Priority: very low It seems few people are using this, although it still works

Unit testable:

Scenario testable:

17) ./mw.FirefoggTransport.js	Priority: very low It seems few people are using this, although it still works

Unit testable:

Scenario testable:

18) ./mw.FlickrChecker.js	Priority: low Only used by admins at this moment

Unit testable: Difficult as written without also calling the real Flickr. If we could abstract Flickr API would be better

Scenario testable: Possible but it is intimately related to interface, i.e. 'flickrInterfaceReset' on the wizard

19) ./mw.FormDataTransport.js	Priority: high

Unit testable: ???

Scenario testable: ???

20) ./mw.GroupProgressBar.js	Priority: medium This seems to be problematic, so it needs more tests

Unit testable: yes - but, it needs a LOT of setup and is tied to DOM

Scenario testable:

21) ./mw.IframeTransport.js 	Priority: high Uploads with a POST that is targeted to an iFrame. Used in old IE primarily

Unit testable: possible but we need to create a URL to load, or otherwise manipulate the iframe

Scenario testable:

22) ./mw.LanguageUpWiz.js	Priority: medium Language picker. Also some code for guessing the "closest" language given a string.  Perhaps this ought not to exist. Don't we have a language picker now?

Unit testable: - closest language - easy - can check on cached menus

Scenario testable:

23) ./mw.MockUploadHandler.js	Priority: n/a This *is* test code.

Unit testable:

Scenario testable:

24) ./mw.units.js	Priority: low Formats bytes to K, MB, GB, etc.

Unit testable: easy

Scenario testable:

25) ./mw.UploadWizard.js	Priority: high Master object controlling the whole interface. Not easy to test as unit.

Unit testable:

Scenario testable: Yes

26) ./mw.UploadWizardDeed.js	Priority: medium Can look up licenses remotely.  Classes for Deeds, which comprise a license and a form and  turns them into wikitext on command  Deed Chooser, which responds to messages like 'selectDeedInterface'

Unit testable: yes - create deeds with appropriate properties, test generated wikitext? deeds can also create forms on the page, we can add data or remove to test validity checks.

Scenario testable:

27) ./mw.UploadWizardDescription.js	Priority: medium Basically just a pair of form elements -      language menu plus textarea that can render itself as wikitext, with some restrictions on contents      can also be 'required' or not since only first desc is required

Unit testable: yes, create one of them, enter data, check results

Scenario testable:

28) ./mw.UploadWizardDetails.js  priority: medium  Big glob object that contains all the things that comprise the details.  Main job is to make wikitext, then submit it to server and pull upload out of stash  Also has stuff that copies metadata to other details (ick)

Unit testable: difficult, requires a lot of setup

Scenario testable: might be easier, if we can test what generated wikitext before or after submission

29) ./mw.UploadWizardInterface.js priority: low Represents the entire multi-step interface.   uploadwizard config can affect static stuff above the wizard but otherwise this is   pretty boring HTML generation

Unit testable:

Scenario testable:

30) ./mw.UploadWizardLicenseInput.js priority: high  Based on config, create radio buttons and groups thereof  Also can do some API stuff, like recurse to find valid licenses in wikitext and/or check if it is parseable

Unit testable: yes, although requires a good deal of setup

Scenario testable:

31) ./mw.UploadWizardPage.js	Priority: low boring, does little. Just sets up everything

Unit testable:

Scenario testable:

32) ./mw.UploadWizardUpload.js	Priority: high The object behind the file input.   Can extract metadata, thumbnails, etc. on file input change.  Publishes events while uploading.  Gets stashimage info after success  Changes appearance when successful, publishes other events.

Unit testable: wow.... um, maybe?

Scenario testable: more likely

33) ./mw.UploadWizardUploadInterface.js priority: high Describes the uploads at the file stage. The companion of UploadWizardUpload

Unit testable: should be yes - events are triggerable with callbacks or other browser events

Scenario testable:

34) ./mw.UtilitiesTime.js

Unit testable: yes, simple seconds to duration

Scenario testable: