After this week’s release of 1.0-beta1 we thought we’d get around a substantial blog post. But since Daniel had to tell about a feature addition to the qooxdoo Simulator, this might be a good idea to raise awareness about testing.

Testing

The area of testing web applications, in the sense of ensuring quality over a longer period of time, can involve quite a number of measures. Here, I’d like to remind you of taking advantage of the following three, that are fully supported by qooxdoo:

• Code Validation: it is so trivial to use, in fact only a generate.py lint call inside your qooxdoo project, and you’ll get a checklist of all the typos, mistakes, ugly or potentially dangerous code, etc. Don’t worry about the amount of warnings when you use qooxdoo’s ecmalint tool for the first time. Just work yourself through the checklist from top to bottom and fix all the issues. Typically there are much less issues to fix than the length of the initial list suggests. BTW, for the qooxdoo framework and the built-in apps we’re basically down to zero “real” issues.
  
  
• Unit Testing: there’s no way you can reasonable well develop software – particularly in an “agile” way or in an scripting language like JavaScript – without proper (unit) testing. qooxdoo comes with a complete unit testing framework: just put your own unit test classes into the test folder inside your top-level app namespace, and run generate.py test from the command shell. This will create the TestRunner for your application, and you can select and run any of your unit tests. If you’re into it, you can also do test-driven development (TDD), as qooxdoo supports this for the “source” version of your app with the test-source target of the generator. qooxdoo itself has more than 1.300 unit tests (and counting), which are automatically run each night on 30 “browser x OS” combinations.
  
  
• Automated GUI Testing: Ever wondered how you could have an “invisible user” that interacts with your app in all the browser x OS combinations you’re interested in? Well, then the qooxdoo Simulator is the tool of choice. It’s based on the Selenium RC infrastructure and comes with a so-called “qooxdoo user-extension” that has many built-in commands that let you easily write test cases for your app. Of course, this kind of testing might be a bit harder to setup, but then it really pays off. qooxdoo runs quite comprehensive simulations for 6 of the built-in apps in a total of over 160 simulations, plus the startup of each of the more than 200 samples of the demobrowser. This is done each night, and yes, it takes time.
  
  

If you care about software quality and testing, you should definitely go for the first two if not all three of the tools mentioned above. But now to yet another improvement of the Simulator:

Simulator: Simplified typing

When creating an automated test case for a qooxdoo application using Selenium, simulating a user entering text into a form widget could be a bit tricky. For Selenium’s type and typeKeys commands it’s necessary to use a locator that finds the HTML input or textarea element of the widget. For widgets like qx.ui.form.ComboBox, this meant digging into the DOM structure to find the qx.ui.form.TextField child control’s input element. With the qxType and qxTypeKeys commands newly added to the Simulator contribution, a test developer only needs to specify a locator that returns any DOM element that is a part of the widget to be typed in. The qooxdoo Selenium user extension will then search for the corresponding HTML input or textarea element. This is especially convenient when assigning IDs to widgets, e.g:

In the application code:

var comboBox = new qx.ui.form.ComboBox();
comboBox.getContentElement().getDomElement().id = "comboBox42";

In the test case:

qxSelenium.qxTypeKeys("comboBox42", "Some text");

That’s it for now. Since there’s Thanksgiving weekend in the US today, many of you will probably read this next week. The qooxdoo core team at 1&1 is going to enjoy tonight another legendary and fabulous Xmas party with many colleagues. C U.

Welcome to another round of tidbits from the qooxdoo world. WebTech09 has passed with some interesting presentations and meeting people (see more in this weekly), and now we’re off to higher goals…

1.0 Beta

1.0 – we’re getting there. As announced earlier we plan to ship a 1.0 beta of qooxdoo this coming week. It’s a preview release, and everybody is invited to check it out and provide feedback. If you want to hold your breath, hold it around Wednesday .

Framework

Script Core

A small change can sometimes reveal bugs which are otherwise hard to find. Fabian changed the event which triggers the placement of a widget from resize to appear and suddenly disappear events from widgets were not fired any more. With this trail in mind we found out that unregistering an appear event will also unregister a disappear event and vice versa since only the target hash code was used to store the data. The fix was quick and easy: store the data using both the target hash code and the event type.

Data Binding

We added some work into the data binding this week. First, we added a data store for JSONP. On top of that, we added a YQL data store. The whole story can found in a separate blog post.

Performance

Performance is always an issue and with the 1.0 release on the horizon even more. We have identified a few bottle necks, which we could remove:

• setStyle vs. setStyles: All CSS styles in qooxdoo are applied by calling qx.bom.element.Style.setStyle(). This resulted in a lot of function calls and some duplicate operations. To solve this we have enhanced the setStyles() function which is able to set several styles at once. We basically have manually inlined the code of setStyle() and moved as much as possible out of the loop.
• Assertions: Even if assertions are mostly used in debug code, it’s still important that the checks are as fast as possible. The assertion class has been reworked internally which gained some significant performance improvements.
• Dispose: While measuring performance we were surprised how expensive disposing of objects is. One small optimization was the deprecation of the _disposeFields method, which basically sets the given fields to null. Instead we set the fields directly to null which is equally concise but way faster.

History Manager

New browsers including IE8 Firefox 3.6 and newer WebKit based browsers support the hashchange event, which is fired whenever the fragment identifier (hash) of the URL changes. If available we now make use of this new feature to detect hash changes instead of the more expensive polling technique. In addition some issues in IE have been fixed as well.

Bugs

For a complete list of bugs fixed during the last working week, use this bugzilla query.

Applications

We introduced a new feature for the API Viewer this week: The throw information will be displayed for every method which can throw errors. qx.data.MBinding is a good example for this new feature.

Generator Configuration

The generator has a new command line option -m (or –macro for the long form) that  allows you to pass macros and their definition to the generator. Example:

generate.py -m foo:bar myjob

where foo is the macro name and bar the assigned value. You can specify multiple -m options. The effect is as if you wrote these definitions in the global let section of the configuration file  you use. Since these macros are evaluated very early, you can use them e.g. in top-level include keys if you want to parameterize an include file. In this vein, macros are now also supported in jobs’ extend and run keys; this was formerly not supported, as these keys are among the earliest keys that are evaluated in a job (prior to full macro expansion), as they guide job construction.

That’s it for this week, see you around next time.