Let’s test Ubuntu NOW!

Making Ubuntu better, if possible

Posts Tagged ‘ldtp

Some updates on Mago

leave a comment »

I have been busy with the release of Ubuntu 10.04 LTS and, although it may seem that Mago activity has decreased, there are some news related to the project that I want to share before UDS.

Ubuntu 10.04 LTS has been released with Mago 0.2, which is the release of Mago compatible with LDTP 2.0. Earlier this year, LDTP team released a complete rewrite of the testing framework in Python. After LDTP 2.0. arrived in Lucid, Mago suffered some weeks of instability, until it was working again with the new API. Also, I gained upload rights for ldtp and mago packages last week and, hopefully, this will be reflected in more activity during the Maverick cycle.

There is going to be work related to GUI testing during Maverick cycle, and some of them have been already reflected as blueprints for discussion during UDS:

Mago internationalization:
Mago works only with “C” locale applications. We need to modify it in order to make it work with different locales. This will be useful for local Ubuntu derivatives and to test language packs.

Mago Daily:
We aim to be running Mago tests on a daily basis. One of the biggest challenges to achieve this is having perfect integration of Mago with Checkbox. We will be discussing previous problems and will try to find a solution.

Roundtable: GUI Testing:
We will be discussing the different solutions for GUI testing available, their advantages and disadvantages. Sikuli, Mago, kvm-autotest, among others.

So, if you are coming to UDS (or want to participate remotely) and are interested in automated GUI testing, feel free to subscribe to those blueprints and participate in the discussion. See you all there!

James Tatum, a Mago contributor who is also coming to UDS, points me to another blueprint for discussion.

Simplify the creation of tests in Mago:
Adding applications to the Mago library is cumbersome. To foster the creation of more test cases, we will discuss ways to make this easier.

Written by Ara Pulido

May 3, 2010 at 2:26 pm

Posted in mago

Tagged with , , ,

Accessibility (lack-of) information

with 3 comments

One of the main issues when getting information from the AT-SPI layer is that most of the accessibility information is missing. Names are almost never set, therefore, objects take the name of the current text.

This is something generally painful, as tests will need to be localized for each language. Let’s imagine that we have a form called “Update Manager”, then the object would be frmUpdatemanager. If we change the target system language, let’s say, to Spanish, then the window will be named “Gestor de Actualizaciones”, and the accessibility information in this case would be frmGestordeactualizaciones.

As I wrote in my previous post, we are trying to separate as much as possible this kind of information from the scripts code. Apart from having classes for the common activities with applications, the text in windows, buttons, etc. is maintained in a separate file, ubuntu_constants.py that will be, eventually, the only file to be changed when porting the tests to a different language.

Written by Ara Pulido

August 7, 2008 at 3:24 pm

Posted in Uncategorized

Tagged with , ,