Practical GUI testing using SikuliX

Rejoice with me - after much banging of head against various walls, I have finally succeeded in building a GUI test out of Java, jUnit, Gradle and SikuliX 1.1.0. It starts a new game in the Mac OS Chess application, enters the opening move using drag/drop, and quits the application (answering correctly in the "save" dialog).

The secret was to give up on the idea of using the Python test script fragments created in the SikuliX IDE directly. Rather, I now translate these scripts line by line into Java; e.g. from
wait("xyz.png")
to
screen.wait("xyz.png");

Each short Python script is converted to a simple method on an object representing the application or individual screen under test. These methods can then be invoked as fixtures from any test framework, e.g. jUnit or Fit. The resulting test suite is built with Gradle and can be run as a standalone application to test the target application end-to-end.

One of the tricky bits was to set the image search path correctly so that the images embedded in the jar file can be located by the SikuliX API, whether you're running in the IDE or standalone. By storing a dummy SikuliX script within the src/main/resources folder (e.g. images.sikuli) you can use the SikuliX IDE directly to capture and fine-tune images for use in your tests.

Depending on the CI environment of the project, another tricky part may be to provide both the application under test and the test suite with a graphical pseudo display on which to run, but there is quite a lot of advice in the SikuliX documentation as well as on Stack Overflow about that.

Next steps:

• Test this approach under Windows and Linux too
• Enable the use of FIT in place of jUnit (more appropriate for whole-system tests)
• Make use of the optional Tesseract library to read back values from the screen
• Build and run test suite in various CI environments

Mercurial - managing a repository

Last Autumn, I set up a repository server with Mercurial. While not particularly difficult, it took a while to get all the configuration exactly correct, in particular, to leave no security loopholes. With some assistance from Zuhlke's IT centre, this was satisfactorily completed and the server is in production use.

It takes a little while to get used to the idea that you can't just access files directly from the repository server, as you can with CVS and Subversion. Instead, anyone wishing to get hold of the repository contents has to install a copy of the Mercurial software on their own machine (on Windows PCs, my choice would be TortoiseHg) and "clone" the repository. While this makes it a bit tedious for someone who just needs one or two files out of a big repository, it's great for teams of developers who can each check files in and out of their local workspace before merging a consistent set of changes with the central development branch.

I was quite surprised, however, by the lack of web-based admin facilities. There ought to be a control panel to allow suitably authorised people to create and delete collections of repositories with specified access permissions, set up and delete repository user accounts etc. Currently you have to use the shell commands and in some cases, this involves superuser privileges (e.g. to change ownership of new repositories to www-data so that the Apache FCGI scripts can access them).

Because I was unable to find such a facility either natively or under Webmin, I have embarked on developing some scripts to provide these functions. I have adapted the Python scripts and modules, HTML templates and stylesheets of Mercurial itself for the purpose. Anyone keen to help or to get access to this code is invited to contact me - immo.huneke _a_ zuhlke.com.