test: Test Runner wdio-qunit-service

[mauriciolauffer]

Adding another test runner alternative: WebdriverIO Qunit Service, a simple drop-in replacement for Karma JS (karma-qunit, karma-ui5, etc).

wdio-qunit-service in:

• WebdriverIO documentation

• QUnit integrations

• NPM

I've isolated everything in the folder test/wdio-qunit to make it easier to spot the config.

[flovogt]

Thx a lot @mauriciolauffer. Could you please adjust the PR to use the test starter concept instead of providing separate HTML files for starting the test?

[mauriciolauffer]

hi @flovogt
Currently, sap/ui/test/starter is not supported in wdio-qunit-service because Test Starter manually patches QUnit object before it being loaded. The config property is manually added to QUnit in sap/ui/test/starter/_setupAndStart.js.

Also, Test Starter is an in-browser test runner which, IMHO, doesn't make sense. Especially when you want to use a proper test runner...

I'll try to add Test Starter support to wdio-qunit-service soon.

[codeworrior]

...because Test Starter manually patches QUnit object before it being loaded. The config property is manually added to QUnit in sap/ui/test/starter/_setupAndStart.js.

I wouldn't call this a patch. The test starter rather makes use of QUnit's documented preconfiguration feature, which allows to provide configuration in time, especially when loading everything asynchronously.

Whether Test Starter can be called a Test Runner or not, is an interesting question. I never saw it as a Test Runner (something that executes multiple HTML test pages and collects the results?). The main purpose of Test Starter is to free HTML test pages from boilerplate code, esp. when it comes to the non-trivial orchestration of loading QUnit, SinonJS, Sinon-QUnit bridges and bootstrapping UI5, all async and in the right order without starting QUnit queue processing too early. Test Starter was originally written for the UI5 framework and its libraries, where we have many tests per library. This initial context drove the decision to add support for testsuites (collections of test pages) and to store the per-test configuration in those suites. The built-in connection to UI5's simple in-browser test runner (button "Run All" in a suite launches the testrunner.html for this suite) was added on top and ensured compatibility with the previous testsuite implementations. But besides that button, Test Starter and testrunner.html are rather independent.