Page MenuHomePhabricator

Investigate unit test coverage of Cite visual editor JS
Closed, ResolvedPublic

Description

Aim: Make sure that we have a good unit/integration (e.g. QUnit) test coverage of the JS code in the VisualEditor Cite code

Tasks:
In Visual Editor & Cite extensions:

  • Determine what the latest method of JS code coverage is across active MediaWiki extensions. "nyc"?
  • Analyze existing test coverage of the JS code
  • Check if test coverage reports are generated
  • If missing test cases are identified, create subtask for parent ticket for creation of new unit tests

Event Timeline

awight renamed this task from Investigate test coverage of the JS code in the VisualEditor Cite code to Investigate unit test coverage of Cite visual editor JS.Feb 28 2024, 12:48 PM
awight updated the task description. (Show Details)

Change 1010183 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Cite@master] [WIP] Add QUnit tests for all .js classes in ve-cite

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

Change 1008454 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Cite@master] Add basic PHPUnit tests for Parsoid implementation

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

Change 1008454 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Add basic PHPUnit tests for Parsoid implementation

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

Change #1010183 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Add initial QUnit tests relevant for reference re-use in VE

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

Overview of my findings:

  • Test coverage for Cite's VisualEditor integration is effectively non-existent, neither via unit nor browser tests.
  • A good amount of code is more wiring/glue than anything. E.g. …Action, …Command, or …ContextItem classes. This it naturally hard to test individually, but that's fine. The files barely contain any code anyway. They are sufficiently covered by browser tests that rely on the features.
  • …Node and …Model classes sound like they are leaf nodes in the general tree of VE data structures, but unfortunately aren't. ve.ce.…Node classes bind against …Model classes. …Model classes bind against the entire Document.
    • The two ve.dm.…Node classes are the best candidates for individual coverage. We already found bugs in them, see T359943.
  • The following features are also worth being covered individually, in my opinion:
    • The re-use dialog builds an internal search index that contains all visible and some invisible information about each ref. Tests should make sure that e.g. the index is updated when references are edited.
    • Reusing an unnamed ref auto-generates a name like :0. We should e.g. test when this happens (immediately, i.e. the :0 becomes visible during the session, or only after save?).
    • There are a few …Widget classes. These are great candidates for unit tests. Naturally widgets should have no coupling whatsoever.