wikimedia/mediawiki-extensions-Popups
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/Popups synced 2024-11-16 20:18:00 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Popups/docs/adr/0007-prefer-running-qunit-tests-in-node-js.md
Thiemo Kreuz 7ef925fb97 Prefer YYYY-MM-DD ISO dates in all documentation 
It is probably not that critical to understand if "09/11/2016" refers
to September 11th or November 9th. I still think it's worth looking for
a documentation format that is easy to understand by an international
developers community. My personal best practice is to use the ISO format.

Change-Id: Ib209a8a1651970d74f82c188ae4b84d1a4eb534e
2019-01-17 17:11:29 +01:00

1.6 KiB
Raw Blame History

7. Prefer running QUnit tests in node.js

Date: 2017-03-08

Status

Accepted

Context

QUnit tests were set up to run on a browser or phantom.js on top of a running mediawiki server.

We want to:

  • Speed up the test running in a development cycle
    • Full page reload every time you change tests or source takes too long
  • Leverage common.js in our tests to load our sources and other test helpers like stubs
    • Remove global variables

Decision

QUnit tests will be migrated from tests/qunit/ext.popups/ to tests/node-qunit/ and will be run by the script npm run test:node in a node environment with access to QUnit, a fake jsdom, and jQuery. Powered by the node package mw-node-qunit.

Node tests will be run in CI too in the npm job that runs npm test.

It is preferred to use the node-qunit test environment, as it is fast, leverages common.js modules, and isolated.

When impossible because of extreme coupling with mediawiki.js, put the integration tests in tests/qunit/.

Consequences

  • README has instructions on how to run different types of tests
  • Node based QUnit tests...
    • can be run independently of mediawiki
    • are isolated and need to stub global variables used in sources
    • are run in node.js 6+ which runs in CI on wikimedia infrastructure
      • which means they leverage that platforms advantages (loading files with common.js, using es6, using the node stdlib if necessary)
  • Most tests are migrated to tests/node-qunit and only the ones that strictly need it remain in tests/qunit (processLinks.test.js for example, see comment in file)