Developer Log

This post tries to give some links and context to my last one (GTK+ unit tests brainstorming (conclusions)), so people interested in this topic can follow all the story behind the work on Gtk+ unit tests.

The last GUADEC in Barcelona the build-brigade was born. Some of the tasks of the build-brigade have to do with the deployment of a continuous integration system for Gnome, as well as to take care of testing and the integration of these tests, among other quality tools, into the continuous integration system. You can have a look here (Gtk+ integration loop), here (Gtk+ module integration loop details), here (Gtk+ module tests results) and here (Gtk+ module tests code coverage statistics) to see a sample demo of what I mean for GTK+, but the idea would be to extend it to all gnome modules.

Igalia, the company I work for, is interested in helping with this to become real, and thus, encouraged me and my partner -and also friend- Dape, to work on the build-brigade to this purpose. Dape has been working more on the continuous integration tool side (you can see his latest posts on his work here, here or here), while I’ve been working more on the testing side.

Regarding my work on the testing side, thomasvs, another member of the build-brigade, told us that there was people inside GTK+ that would be interested in having some Check based unit tests. We were already using Check here in Igalia, so that was nice.

Fernando Herrera warned me that there was a previous project of Sun that aimed the same target, gtkvts, and a forked (and maintained) version of LSB, so I first took a look at it, then I tried to (unseccessfuly) get feedback from GTK+ people and finally drop my conclusions here and here. Basically, I think that starting from scratch and trying to get feedback from GTK+ guys (using a buildbot demo as Fer suggested) would be better.

Thus, I started writing some unit tests for GTK+ using Check and following a similar approach as the one pointed out by Stefan Kost in his GUADEC presentation on check based unit testing, while, at the same time, I tried to get them integrated into the buildbot demo that Dape was preparing. Once I had something functional to show, and integrated into the buildbot demo so people can see the whole picture underneath, I asked for feedback to Gtk+ guys.

After that, a successful brainstorming was started by Tim Janik on this topic, and now, I’m trying to get a set of conclusions to start the work in a proper way, which was the topic of my last post. I think this has been all till now 🙂

These last weeks there has been an interesting brainstorming in gtk-devel about developing unit tests for Gtk+. A lot of people joined and give insight on this topic, it is great seeing so many people interested in this stuff. Now it is time to reach conclusions and there are some hot topics that still need to be decided:

• Will we use a testing framework like Check or finally develop something specific for Gtk+?
• Should we stop the test suite after the first failed test or should we get a complete list of failed/passed tests?
• Should we fail a test whenever we reach a critical/warning?
• Should we test segmentation faults by forking every single test?
• and more … 🙂

If you are interested too, check it out and help us make the best choices 😉

I have sent an email to gtk-devel in order to get feedback from the Gtk+ community about the unit tests project I’m developing from Igalia. If you are interested you can check it out here.

If you have any comments or suggestions feel free to answer it or reply to this post :).

I have spent some time working on developing some unit tests for Gtk+ using Check. You can check them out here:

cvs -d :pserver:anonymous@cvs.igalia.com:/var/publiccvs co gtk+

You need Check installed in your box in order to be able to run the tests or otherwise these will be disabled at configure time. You can get Check from here. You can also get it with apt in a Debian like system just typing apt-get install check.
Once you have downloaded, configured and built the repository, you can type make check in order to run all the tests in the Gtk+project. If you just want to run my unit tests you can just run make check from inside the ut/ subdir, where I have put all my tests. You should also be able to browse my tests on-line using Bonsai.
My folk Dape is also working for the build-brigade. He is working on the continuous integration tool (buildbot), improving it with nice features that will come in handy when setting up a nice Buildbot for the entire Gnome project. Meanwhile, I have to thank him for setting up a buildbot for my version of Gtk+ (the version where I added my unit tests) and its dependencies here. From that view you can check the builds, the tests logs and even some great code coverage statistics that are very useful to know which code is actually being tested/executed by the tests I have developed.
If you are interested in this topic and want to contact us you can join #build-brigade IRC channel at GimpNet or subscribe to the build-brigade mailing list.

Igalia is already five years old, so:
Happy birthday!

Gtkvts is a huge collection of tests for Gtk+ created by Sun and later forked by LSB. Fernando Herrera warned me about it some time ago when I was thinking about creating a test suite for Gtk+. Since then, I have spent some time reviewing it and it is really huge and complete, but has some things that I didn’t like too much: tests that are bad implemented or do not compile and the conversion tool they use to make the tests framework-independent among others. These issues drive me to think that developing tests from scratch could be a better approach this time. Anyway, we can still use gtkvts as a reference for lots of things, after all, there is a lot of work in it.

In the past weeks, an Igalia folk who has a non tech profile and I were looking for a topic were she can get involved in the Gnome community.
We reviewed this page, which turned out to be a nice starting point. She specially liked the accesibility issue and also found interesting the usability topic and the translation project. I’m sure she can give an interesting and different point of view. If you are already working on any of these Gnome topics and need some help, just tell me! 😉
Regarding usability, my folk Sergio proposed an interesting idea: design a “Your first steps in Gnome”, which would analyze and propose ideas regarding how to guide and train a newbie in the desktop usage. I’m sure this would be very useful for people not used to work with computers or even for people who come from other desktop environments.

If you have any other ideas about how a non tech profile can help in Gnome, let me know, they will be very appreciated 🙂

It is still not clear if the new Single Instance Application Framework that is being developed by Vytas will fit Gedit needs. For the moment, Paolo Borelli suggests to wait:

“I guess at the moment we should still wait and see what comes out of
Vytas work and where in the stack (glib/gtk/gnome) is going to be put.”

I think he is right, let’s wait for it and evaluate how it fits Gedit at that moment.

After three nice weeks of rest I’m back to fully retake the work on build-brigade. Let’s go for a demo of the gtkvts test suite running under some kind of continuous integration system like buildbot, tinderbox or jhautobuild.

I will be on vacation till the end of August.
So… see you around!