Was added for wdio-related code, but not used in the end.
The only reference to this module anywhere in Wikimedia Git is
mediawiki/extensions/CirrusSearch, which doesn't use it for
its regular or daily tests, but rather the integration test,
which already has its own copy of this module in package.json.
Change-Id: Ifdf4362077f4684a2866363e35d0aca2f89f48b5
Code and integrity from <https://code.jquery.com/qunit/>.
Release notes at <https://github.com/qunitjs/qunit/releases>.
Highlights for the browser version:
- [2.7.0] Reporter: Remove cost of DOM size when
using "hidepassed=true".
- [2.7.0] Reporter: Use perf.now() for improved accurracy
of unit test durations.
- [2.7.0] Reporter: Make debugging tests in a browser
easier by adding timeline markers for DevTools.
Highlights for the npm package / CLI version:
- [2.9.0] CLI: Reduce dependency tree size
from 143 packages to 9 packages.
Change-Id: I38408d90765cd18d5dd6952b8b6b30cbfa0c7ed5
Selenium tests run fine when targeting MediaWiki installation in
MediaWiki-Vagrant and in Jenkins, but fail when targeting beta cluster.
Until tests are refactored to run without failure for beta cluster, let's disable
failing tests.
Bug: T185011
Change-Id: I12da893e7d624d4ebe478bccf0706aa07c965796
selenium-daily just calls selenium-test. It's needed for daily Jenkins job targeting
beta cluster. The script might seem redundant, but it provides flexibility. In case
a repository does not want to run all tests daily, that's easily fixed by updating
the the script.
Bug: T188742
Change-Id: Idf86f94cc31abda4bfcdc1ac4eba29206d9c91f9
This is new package will be reusable by other repositories for
their browser tests, without having to reference the internal
selenium/pageobjects/ directory from MediaWiki core.
In addition to not requiring direct imports, it will also avoid
problems in the future by allowing the package to be versioned
and iterated upon without forcing an atomic global upgrade
(or broken master builds), everytime we change something.
See wdio-mediawiki/README for details.
Within MediaWiki core itself, the package is used using the
'file' specifier in its package.json, so that we always test
and develop using its working copy, which makes drafting and
testing changes easier.
Also misc changes to make wdio.conf easier to understand.
Bug: T193088
Change-Id: I547a7899e7a97693a93567dd763784e637433d55
This is functionally a no-op, purely refactoring (mostly style).
* Consistently require packages at the top of a file.
(e.g. MWBot in edit.page.js).
* Remove unused .call(this) from mwbot interaction closures,
which didn't use 'this'.
* Use Node.js regular Promise chaining with then(), instead of
complex bluebird.coroutine generator function yields, which
are intended to emulate async-await, but the syntax is quite
error-prone for inexperienced developers and hard to debug.
Once we require Node 7+ for the selenium tests, we can use
async-await here natively, but until then, might as well use
regular then() syntax, which we already use elsewhere in the
tests, and is also what MWBot documentation uses.
* Also applied some minor whitespace changes for consistency
among these files and other MediaWiki JS. E.g. no empty line
before the first statement of a function. Add a new line between
different methods, and between the end of a class and the
export statement.
* Remove 'use strict' from test files. The patterns that would expose
the bad non-strict behaviour are mostly already forbidden by ESLint,
and the run-time optimisation to disable non-strict can't be noticed
in tests (more useful in prod where e.g. the same process would run
a function 1 million times). Main reason here is to keep things
simple for new-comers and reduce boilerplate, given that these tests
will mainly be worked on by browser-JS developers, not Node.js devs,
and we don't currently use strict mode in our front-end code, either.
* Remove unused bluebird dependency.
Bug: T193088
Change-Id: I59f9211299e8e884c28c7733bcee3b7b28542610
Doesn't seem to add anything, except complexity.
This has the benefit of matching more closely the way the README
recommends running individual tests.
Also add a check for 'chromedriver' before running it.
Normally the -e and pipefail would suffice, but because
it runs in the background, the error can be buried,
hard to find, or even not cause exit code to be set
properly. Thus, do a simple 'hash' check that will
print a useful command and exit cleanly.
Before:
> $ something &
> [1] 57922
> -bash: something: command not found
> [1]+ Exit 127 something
> $ echo $?
> 0
After:
> $ hash something
> -bash: hash: something: not found
> (exit: 1) $ echo $?
> 1
Change-Id: Id95f18927b5443defe679a77a82c5cbdd127c716
This makes it possible to use in Quibble. Right now, Quibble
cannot use 'npm run selenium' yet because it sets up its own
chromedriver, which would conflict with selenium.sh.
But, in preparation for Id95f18927b5, we can at least abstract
the test command so that it can easily be changed without having
to update Quibble and without having to worry about it being the
same in all MediaWiki branches.
Bug: T179190
Change-Id: I622ec3bf36746502cae891cc6bec23982b21f876
Just running `npm run selenium` in CI does not work. If WebdriverIO fails, the
job still passes since the last command to run is `killall chromedriver`.
Reusing the script from CI that starts and stops Chromedriver should fix the
problem.
Bug: T179190
Change-Id: If29227263d23a3e4f26e2329dfa13c49f976cf8e
Bluebird is implicitly installed on my machine, probably because I have a recent npm version. It needs to be explicitly installed in MediaWiki-Vagrant, probably because of an older npm version.
Bug: T190914
Change-Id: I9c704502fb5e20abf9b21d483723eb55b6fb3875
The running of 'grunt qunit' is unconvenient due to it only working
if the user has grunt-cli installed globally, which should not be
needed because it is already installed in the local directory.
It could be worked around by instructing users to use
`./node_modules/.bin/grunt qunit`, but it would be much simpler
to instruct them to use `npm run qunit` instead.
Unlike 'composer', 'npm' does not come by default with a command
like 'composer exec' that one could pass a command directly
without needing to register it. This is fixed in more recent
versions through 'npx -c', but that's a bit too new to require
in the manual, so adding it as a run-script instead.
Change-Id: I2812b13dbed50612b1626a617ba65f92e212f01a
