Javascript API Test Suite

[Aaron J. Seigo]

On March 29, 2010, Josip Lisec wrote:
> I would like to work on JavaScript API Test Suite [1], while I

great :)

> consider myself quite knowledgeable about JavaScript and I have a
> working knowledge of C++, but I'm not that familiar with Qt and KDE
> codebases, so I'm wondering where could I find more about
> QMetaObjects,

QMetaObject is documented in the Qt API documentation, but i don't think there 
will be any use of them in the testing system. the tests need to test the 
resulting JS API; that some of it is generated using QMetaObject <-> QScript 
"magic" is a hidden detail to the tests.

> as well how tests would be executed.

that's one half of the project, really: to create a test harness that will 
execute the tests.

the goal should be to have a directory full of JS test snippets that can be 
run either one at a time or all at once in serial fashion. the results of a 
run of tests should be colated and shown as a report either on console or in a 
nice graphical app.

that will be one of the important points to figure out for the proposal, in 
fact: what will the app used to run the tests look like? will it be a C++ 
application that wraps a Javascript Plasmoid (essentially a simplified version 
of plasmoidviewer that can load and run tests), will it be a Javascript 
Plasmoid itself (while possible, this raises the of using the framework to 
test itself; perhaps not a big problem though)

> I guess that currently most of the JS API have no tests, writing them
> is also part of the task, right?

yes.

> I considered that slightly modified version of jQuery's unit testing
> framework [2] could be used to provide the framework for testing, as

the jQuery unit testing framework looks interesting; probably the biggest 
amount of work in re-using that, i imagine, will be to remove the assumption 
that it is running inside an html document. it might be possible to export a 
document object into the QScript environment that bridges to a QWebFrame? 

probably the first step will be to document what kind of tests will need to be 
written. the core of the tests will consist of:

* ensuring the global plasmoid object exists, that it has the expected 
properties (and that they return sane results when checked) and that 
properties that should be writable are and properties that aren't writable 
aren't

* ensure that all of the Qt utility bindings (QRect, QPoint, etc..) all work 
as documented

* check each of the UI elements (pushbuttons, checkboxes, etc) for existence 
and proper property sets

* check each of the layout classes

* check the DataEngine and Service bindings: fetch a DataEngine, request a 
source from it, connect to a source and check the data (that would be an async 
test), connect to a source with an interval suplied (another async test), call 
query() and check the data returned, request a service related to a given 
source ...

* check each of the API extensions (FileDialog, LocalIO, etc)

etc ..

using http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API as a 
guide to what needs to be tested is the way to go to compile such a listing.

from such a list of tests that will need to be written, the set of 
requirements for the test harness can be derived. and then you can probably 
determine is re-using JQuery's framework is worthwhile.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks