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.
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 lintcall 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.
testfolder inside your top-level app namespace, and run
generate.py testfrom 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-sourcetarget 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.