Page MenuHomePhabricator

Support Vue component testing in QUnit
Open, Needs TriagePublic

Description

It is often desirable to integration test Vue components in isolation. The Vue community has settled for vue-test-utils (hereinafter: VTU) as a convenient wrapper for the repetitive creation of app wrappers for such testing. Thus far, we've been using Jest for such tests, which has served us well, but can have issues in some cases:

  • Jest runs tests in jsdom rather than an actual browser. This can occasionally lead to problems with certain components, e.g. at the time of writing, the Popover component in Codex cannot be integration tested in Jest + jsdom due to a dependency crashing with infinite recursion.
  • Jest is unable to load ResourceLoader modules (T390639).

It would be good to have the opportunity to test Vue components using the existing QUnit-based test runner in addition to Jest.

Event Timeline

Change #1141138 had a related patch set uploaded (by Máté Szabó; author: Máté Szabó):

[mediawiki/core@master] Support Vue component testing in QUnit

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

Change #1141480 had a related patch set uploaded (by Máté Szabó; author: Máté Szabó):

[mediawiki/extensions/CheckUser@master] PoC: Add an example Vue component test in QUnit

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

The two issues you raise actually seem like positives to me. Generally I would be worried about encouraging the writing of tests in two different libraries and the fragment it leads to. To be truly honest I would love on the long term for us to move fully away from QUnit to Jest in core and that is at least what I am seeing in new extensions. Jest has various benefits such as quicker execution and code coverage scores/enforcement.

  • testing inside a real browser tends to be slow and I think is better suited for integration tests such as Selenium and Pixel
  • The inability to load ResourceLoader encourages the writing of better unit tests scoped to the functionality of the module being tested.

The two issues you raise actually seem like positives to me. Generally I would be worried about encouraging the writing of tests in two different libraries and the fragment it leads to. To be truly honest I would love on the long term for us to move fully away from QUnit to Jest in core and that is at least what I am seeing in new extensions. Jest has various benefits such as quicker execution and code coverage scores/enforcement.

  • testing inside a real browser tends to be slow and I think is better suited for integration tests such as Selenium and Pixel
  • The inability to load ResourceLoader encourages the writing of better unit tests scoped to the functionality of the module being tested.

Yeah, I've read the relevant discussion at T212521 and related tasks and have been meaning to avoid restarting it :) Just to clarify, I'm not trying to advocate that QUnit be used over or in place of Jest here, I just think improved support for component testing via QUnit would be a neat option to have for teams that have a need to run JavaScript tests in a non-jsdom browser environment, be it because of jsdom bugs, application logic that makes extensive use of more complex browser APIs (like VE) or a preference for integration-level tests.

Change #1141138 merged by jenkins-bot:

[mediawiki/core@master] Support Vue component testing in QUnit

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

Change #1141480 abandoned by Dreamy Jazz:

[mediawiki/extensions/CheckUser@master] PoC: Add an example Vue component test in QUnit

Reason:

Probably don't need to keep the PoC around

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