Archive for the ‘mago’ Category
It’s been a while since the last time I blogged about Mago, but Natty is going to be an exciting cycle for desktop testing automation (a lot is happening!) and I would like to present some of the work we have been doing.
Today I will write about Magomatic, a new side project related to Mago.
If you have tried to add a new testcases to an existing Mago wrapper, you can see that this is pretty straight forward. Most of the things that you need are already there, and you need to add only the code of the test, without thinking on the accessibility information of the application (OK, sometimes you have to, but it is quite simple to start the process). If you, however, have ever tried to add a new wrapper application to Mago I guess that you have found the process a bit difficult: you need to understand how the accessibility information is presented by LDTP, you need to create the application python file, you also will have to create a test suite python file, and a XML data file. This is time consuming and I though it could (and should) be automated.
So I created Magomatic. And how does it work?
Magomatic uses templates and accessibility information to create those files for you. Using it is pretty straight forward:
- Open the application you want to create the wrapper for.
- Run Magomatic:
$ bzr branch lp:magomatic $ cd magomatic/bin $ ./magomatic
- When prompted, you will need to select the window you want to create the wrapper for with the mouse pointer.
- Done! Under the
folder you will find a folder with the name of the application with the needed files to add to Mago and start coding your tests.
This is a work in progress, but the main and most important functionality is already there. We really hope that this will lower the entry barrier to Mago and more people will join us adding new tests in the Natty cycle.
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 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.
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.
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.
This is old news, but I have been busy lately and I just haven’t had the time for a quick post about it.
If you want to learn about Mago and how can it can help you testing your desktop application, the article is a good starting point.
If you search for software testing automation in your favourite search engine you will find a lot of matches about testing automation of web applications, lots of proprietary software to test proprietary desktop software, lots of FOSS to test web applications and some blogs about testing proprietary desktop software.
What about testing desktop FOSS? How do I find people interested in these topics? Is there anybody out there? Hello?
Fortunately, there is a growing community in the FOSS world interested in testing desktop applications automatically. To try to keep things going, we are having weekly meetings at #ubuntu-testing (irc.freenode.org) every Wednesday at 16:30UTC, running for half an hour.
If you are interested in these topics, please, join us and feel free to add any items you may want to discuss to the agenda.
Yes, if you updated your Karmic repositories lately, you can install Mago just typing “sudo apt-get install mago”. What does that mean? Not much, for the moment.
We have packaged the library and harness, but not the tests. Once you have installed Mago in your machine, you can start writing tests using the library, you will be able to run the tests with the Mago harness and get nice reports in XML and HTML. You won’t have the already written tests, though. Tests change a lot, so it does not make sense to keep them in the repositories, which are quite static. PPAs are a much better place for tests, which I am planning to maintain.
I still have a lot of work to be done regarding this: I have to set up the PPA for the tests and update the documentation at the Mago site, to start. Why did I push Mago into Karmic, then? There are two main reason: Feature Freeze and Holidays. Ubuntu development schedule has an important date called Feature Freeze, after which no new packages are generally accepted and only bug fixes are supposed to get uploaded. Karmic FF is happening August 27th, but I will be on holidays since August 14th, so it was now or never (or Karmic+1).
The main advantage of having Mago in the repositories is that, if a project wants to use it as part of the testing of their daily builds, they can set Mago as a Build-Depends of the project and forget about whether Mago is installed or not in the build machine. And, don’t worry, I will be updating the documentation and setting up the tests PPAs after my holidays, but, in the mean time, Mago is there, ready before Feature Freeze. Happy testing!
A year ago I started a project, as part of my work at Canonical QA team, that aimed to have a consistent way to add automated desktop tests to Ubuntu. That project was originally called Ubuntu Desktop Testing.
The project grew and as the GNOME testing community started to be interested in it, we created a mailing list and an IRC channel (#gnome-testing at irc.gnome.org) for the GNOME folks.
The problem about having two projects (one for Ubuntu and one for GNOME) is that it was very difficult to maintain both synchronized. Also, having the project named as another project (Ubuntu Desktop Testing, GNOME Desktop Testing…) confuses people, as they think that it is exclusive for Ubuntu and/or GNOME, which is not true (as soon as AT-SPI gets migrated to D-BUS KDE will also benefit from this effort, i.e.).
So, today, I am pleased to announce “Mago“, a desktop testing initiative that will replace the other two and that can be used to create desktop tests for any AT-SPI enabled linux desktop.
Mago is hosted in Launchpad at https://launchpad.net/mago and you can start adding test cases by just creating a branch of your own and propose merges as you go by.
The trunk branch is owned by a Launchpad team, mago-contributors, that it is a moderated team. Once you have contributed through merge proposals, you can apply to be part of the team and will be able to push to trunk and review some other members contributions. Join us!
P.S. For those interested, “mago” stands for “magician” in Spanish.