El Tramo | Programming

Improving QtTest usability with QtTestUtil

2008-11-06T00:00:00+01:00

As much as I like CppUnit for writing C++ unit tests, I still prefer using Qt's built-in QtTest module for Qt-based projects. This avoids a dependency on an external library, lowering the threshold for running and writing unit tests. Unfortunately, QtTest is very basic, and lacks some useful features such as automatic test registration and running multiple test suites in one test binary. In order to improve QtTest's usability, I started creating some macros and classes that fill in some of the gaps, and bundled them into QtTestUtil. QtTest's recommended way to write unit tests is to compile and link one test suite per class separately, and using the QTEST_MAIN macro to generate a main() that runs this particular test suite. However, this introduces quite a bit of overhead in writing (creating a project file for every test/class), building (linking a binary for every test/class), and running (running a separate binary for every test/class, usually using a custom script) all unit tests. This overhead is especially painful in a project with many classes. All this conflicts with the general rule that both creating and running unit tests should be very efficient, and makes QtTest not well suited for unit testing as it is. A first attempt at solving this problem is by manually creating a main() function that runs all tests. For example:

#include "MyFirstTest.h"
#include "MySecondTest.h"

int main(int argc, char* argv) {
  int result = 0;
  MyFirstTest test1;
  result |= QTest::qExec(&test1, argc, argv);
  MySecondTest test2;
  result |= QTest::qExec(&test2, argc, argv);
  return result;
}

The resulting binary runs all listed test suites. The downside of this approach is that you have to write quite a bit of boilerplate code: every test binary needs to have its own main() function that explicitly runs all the tests in that test suite, and which needs to be put in a file that has to include all the tests separately. In order remedy this, I took the idea from CppUnit to provide a macro which auto-registers a test suite, and makes it easy to run all registered test suites at once. Creating a test suite is now as simple as creating a .cpp file for every unit test, adding a call to QTTESTUTIL_REGISTER_TEST to that file, and compiling that together with a shared main() that does nothing but call runTests() on the test registry. Since this main() does not explicitly depend on any test, QtTestUtil comes with a SimpleChecker.cpp containing this call, and which can be used by all unit test modules. As a result, no module needs to provide its own main() anymore. An example of a unit test module using the macro and the shared checker described above can be found in the Example subdir of the QtTestUtil repository. It is worth noticing that these QtTest-based unit tests are more compact than the same unit test written in CppUnit (because the latter requires you to call a macro for every test in a fixture). This is just a first set of utilities that QtTestUtil provides on top of QtTest. More utility classes and macros will be added as they are needed.

Mixing Cocoa and Qt

2008-08-16T00:00:00+02:00

Qt does a great job at abstracting out platform-specific features into platform-independent C++ APIs. However, sometimes you still need to write platform-specific code for features that are not in Qt (e.g. to access the platform's address book), or to access platform-specific applications (e.g. iTunes) or libraries (e.g. Sparkle). On Mac OS X, almost all interfaces are offered through the Cocoa Objective-C interface, and the interfaces that are written in C++ have been deprecated and will disappear soon in favor of Cocoa. Although the language of Cocoa is different from Qt's, Qt and GCC make it very easy to call these interfaces from within your application. In this post, I will show how this can be done by making an auto-updating application using Sparkle. To create our auto-updating application, we first lay down the auto-updater interface in a (pure) virtual class:

class AutoUpdater {
  public:
    virtual void checkForUpdates() = 0;
};

The Sparkle implementation of this interface has the following C++ header:

class SparkleAutoUpdater : public AutoUpdater {
  public:
    SparkleAutoUpdater(const QString& url);
    ~SparkleAutoUpdater();
    virtual void checkForUpdates();
  private:
    class Private;
    Private* d;
};

Note that I am using the Pimpl idiom to hide Cocoa-specific internals from the API into a private internal class. The actual impementation of the SparkleUpdater needs to call Sparkle's Objective-C API. However, we cannot write the implementation in Objective-C, since the header for our updater (which will be included from within our application) is written in C++. Luckily, GCC's Objective-C++ extension allows you to mix Objective-C with C++ without any problem. So, we create an Objective-C++ implementation of our updater, and put it in a .mm file:

class SparkleAutoUpdater::Private {
  public:
    SUUpdater* updater;
};

SparkleAutoUpdater::SparkleAutoUpdater(const QString& aUrl) {
  d = new Private;
  d->updater = [[SUUpdater sharedUpdater] retain];
  NSURL* url = [NSURL URLWithString:
      [NSString stringWithUTF8String: aUrl.toUtf8().data()]];
  [d->updater setFeedURL: url];
}

SparkleAutoUpdater::~SparkleAutoUpdater() {
  [d->updater release];
  delete d;
}

void SparkleAutoUpdater::checkForUpdates() {
  [d->updater checkForUpdatesInBackground];
}

All we do here is create an SUUpdater (Sparkle's updater class), set it up, and activate it in our checkForUpdates() method. To integrate Objective-C++ classes into a Qt project, qmake provides the OBJECTIVE_SOURCES variable. Knowing this, we add our new classes to our qmake project file:

HEADERS += AutoUpdater.h
SOURCES += AutoUpdater.cpp
mac {
  HEADERS += SparkleAutoUpdater.h
  OBJECTIVE_SOURCES += SparkleAutoUpdater.mm
  LIBS += -framework Sparkle
}

Before we integrate the updater into our application, there is still one detail we have to take care of: if you write Objective-C code that creates objects, you need to instantiate an NSAutoReleasePool to enable Cocoa's memory management. Although we could do this in SparkleAutoUpdater, we're going to put this in a separate initializer class, so we can share this with other Objective-C++ implementations in our application. The body of this class looks as follows:

class CocoaInitializer::Private {
  public:
    NSAutoreleasePool* autoReleasePool;
};

CocoaInitializer::CocoaInitializer() {
  d = new CocoaInitializer::Private();
  NSApplicationLoad();
  d->autoReleasePool = [[NSAutoreleasePool alloc] init];
}

CocoaInitializer::~CocoaInitializer() {
  [d->autoReleasePool release];
  delete d;
}

Now all that's left to do is integrate all this into our application:

int main(int argc, char* argv[]) {
  ...
  AutoUpdater* updater = 0;
#ifdef Q_WS_MAC
  CocoaInitializer cocoaInitiarizer;
  updater = new SparkleUpdater("http://el-tramo.be/myapp/appcast.xml");
#endif
  ...
  if (updater) {
    updater->checkForUpdates();
  }
  ...
}

That's it! If you want to try this out yourself, just download the sources of this mini-project, build them, and off you go. Don't forget to remove ~/Library/Preferences/be.el-tramo.mixing-cocoa-and-qt.plist to clear Sparkle's state cache.

Going Agile with Google Summer of Code

2008-06-26T00:00:00+02:00

Although Psi has had a fair number of succesful Google Summer of Code projects so far, we have experienced some failures as well: the summer before last, 3 out of 6 projects didn't make the final deadline. A project's failure was typically due to not having anything really usable at the end of the summer, regardless of the good work that was done during the past months. To reduce the risk of such surprises, I decided to take an Agile Development approach for this year's ‘Roster improvement’ project. Here are some of the principles of Agile software development (as written down in the Agile Manifesto), and how we apply them to Adam's GSoC project:

The developer frequently delivers working software to the customer. In our case, Adam sends me a working roster every monday, which I can play around with. I then tell him what I do and don't like about it, and he processes my feedback during the next iteration (i.e. the next week). Of course, since the roster is made from scratch, the backend of the roster is completely mocked up during the first weeks. As the project progresses, the backend will become more 'real'.
Working software is the primary measure of progress. This avoids the kind of surprises we had before, where both student and mentor believed everything was going fine during the project, but where nothing could be delivered at the end of the project.
Code is kept as simple as possible: if you don't need something, leave it out. By initially focusing on the roster frontend (while keeping the backend framework mocked up), we ensure that our backend will only be as complex as we actually need it to be. Moreover, we can constantly change our mind about the requirements throughout the whole project without having to throw away the complete backend. This contrasts with the previous attempts we had at reworking the Psi roster, where we started by working out a complex roster backend, but never got to the point where we had something working with this (over-)designed framework, and had to start over all again.
Code is written with testability in mind. In principle, all new code needs to be tested (and preferably even unit tested before it's written), which allows you to quickly refactor while remaining sure that your code still works as before. However, given the very strict time constraints, I'm not sure yet that we're going to apply this Test-driven Development approach (although some claim that the extra time you spend in tests will even pay off in the short term).
Good designs make sure that you can easily adapt your code to changing requirements. For example, a Model-View-Controller-based design seems to lend itself well to the roster, making the (rather complex) roster logic both testable, extensible, and easy to understand.

I'm convinced that these principles will ensure that both Adam and I (and of course all Psi users) will get a succesful result at the end of the project, and that we'll have had a fun time during these 3 months.

:set noexpandtab

2008-06-18T00:00:00+02:00

Google recently published a C++ style guide, containing all the rules that Google code adheres to. Many of the style tips are quite sensible, and well accepted by many developers out there. However, I was surprised to find the following rule:

Spaces vs. Tabs: Use only spaces, and indent 2 spaces at a time. We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.

I never really understood why so many people have such a hatred towards tabs. Is it just because they have seen code where some editor has mixed tabs with spaces (which of course results in a horrible mess)? Or do they have valid counter-arguments, even when tabs are used consistently? Why would you force presentation of your code upon someone if you don't need to? If you use tabs, you don't need rules like ‘indent 2 spaces at a time’: I can choose whether I want 2 spaces, 4, or whatever indentation I feel most comfortable with when reading code. After some discussion, the pro-space people typically come up with the following piece of code, where they have their parameter names aligned:

void SomeClass::someMethodName(int parameterA,
                               unsigned int parameterB,
                               std::string parameterC)
{
    ...
}

No, you can't do that with tabs, that's true. But why would you do that in the first place (unless you're using an editor which does such annoying auto-formating automatically)? When your method name gets too long, it won't fit on your screen anyway. Why don't you indent 2 tabs for your parameter names instead:

void SomeClassWithALongName::someMethodName(
        unsigned int parameterA,
        int parameterB,
        std::string parameterC)
{
    ...
}

Another popular argument is aligning member declarations:


FooClass foo_;
Bar      bar_;

Same remark: why would you do this? Does it really make your code more readable? Besides, it doesn't scale: whenever someone comes along and has to add a VeryLongClassName member, your alignment will be messed up, and you will have to change every member again. My opinion: let the person who reads your code decide how he/she wants to see it, and lay out your code in a way it is flexible to be seen with different view settings. This avoids lengthy discussions about whether tabs should be 2, 3, 4, or 13 spaces wide. Besides, people have been preaching the separation of presentation and content for ages for HTML and CSS, why would this be any different for code?

Unit testing method overrides

2008-03-07T00:00:00+01:00

It probably happened to most of us developers before: while refactoring, you change the name of a virtual method, but forget to change the name of the overriding method in one of your derived classes. Compilation works fine, all unit tests pass, but your program doesn't work: the overriding method is never called. Java (and C#) programmers can avoid this problem by putting @Override (and override) in front of their methods, which causes the compiler to print out an error message if the method is not overriding anything. However, most other languages leave you hanging with this problem. Luckily, with statically typed languages like C++, you can avoid these bugs by slightly adapting your unit tests. Suppose you have a base class Oracle, and a derived class GeekyOracle, defined as follows:


  class Oracle {
    virtual int getLckyNmbr() {
      return 13;
    }
  };

  class GeekyOracle : public Oracle {
    virtual int getLckyNmbr() {
      return 42;
    }
  };

Being a good developer, you unit test GeekyOracle's getLckyNmbr():


  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle* oracle = createGeekyOracle();
    assertEquals(42, oracle->getLckyNmbr());
  }

After a while, you realize that using abbreviations in method names is actually not very good practice, so you change your method name to something more readable:


  class Oracle {
    virtual int getLuckyNumber() {
      return 13;
    }
  };

However, when you compile your program now, it is behaving completely different than before, although all unit tests passed. It requires manual debugging to find out that you forgot to rename GeekyOracle's method as well, causing Oracle's getLuckyNumber() to be executed, no matter what oracle you instantiate. Your unit tests didn't catch this, because they test every method of a class separately, but don't test the class being used in your application. A way to check for this in your unit tests is to make sure that, when testing a virtual method, you always call it on an object that is statically typed with its base class. In our example, our unit test would call getLckyNmbr() on an Oracle instead of on a GeekyOracle:


  void GeekyOracleTest::testGetLckyNmbr() {
    Oracle* oracle = createGeekyOracle();
    assertEquals(42, oracle->getLckyNmbr());
  }

This unit test will fail to compile when you change the method name of the base class, which avoids you end up with the silly bug in your program. If your test allocates your object under test on the stack (e.g. for simplicity), you could use the following alternative:


  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle oracle;
    assertEquals(42, ((Oracle*) &oracle)->getLckyNmbr());
  }

However, since this degrades the readability of the test, I prefer to add a static helper method to my unit test, and write the test as follows:


  static inline Oracle* p(Oracle& foo) {
    return &foo;
  }

  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle oracle;
    assertEquals(42, p(oracle)->getLckyNmbr());
  }

Although I used C++ in my example, this technique should work for all statically typed languages. Advocates of dynamically typed languages claim they can compensate the lack of types by unit testing their classes properly; I wonder how they avoid this kind of problems, though.

User Interface Design for Programmers

2007-10-29T00:00:00+01:00

User interfaces: every piece of software needs one, but no programmer likes to write one. According to Joel Spolsky (host of the popular Joel on Software), the root cause of the problem is the (unnecessary) fear of being incapable of designing user interfaces. He claims that UI design actually is fun, challenging, and doesn't require any artistic talent whatsoever (as opposed to what many programmers think). Since I have to write quite some UI code myself, and always thought it was the most boring and frustrating aspect of software development, I thought I'ld pick up Spolsky's book `User Interface Design for Programmers', and let him try to convince me otherwise. In his book, Spolsky goes through many aspects of user interface design through real-world examples of popular software, showing some do's and dont's, and generally making it sound like a fun and challenging job. I had a lot of fun reading his book, since it is well written, funny, easy to read, and very light (130 pages, including many illustrations). The nice thing about the examples is that he doesn't limit himself to one part of the OS spectrum, but comments (both negatively and positively) on Windows, Mac OS, and even software from the DOS era. And although the examples are a slightly dated (the book is over half a decade old), I still felt like his views applied to all the UIs I'm writing or using today. I would recommend the book to everyone who comes in contact with user interfaces when programming. If you haven't agreed with anything he wrote, at least you'll have had a fun read. And if you do share his point of views, you'll probably end up with having some personal findings confirmed (like `Pull up the Tools→Options dialog box, and you will see a history of the heated arguments that the software designers had about the design of the product'), come off with some new interesting views, and maybe, like me, feel like UI design can actually be fun and interesting.

Testing Psi

2007-10-01T00:00:00+02:00

While the last bugs are being squeezed out of Psi 0.11's release candidates, work on 0.12 has already begun. One thing I'm excited about as a developer is the fact that we're making the Psi codebase `testable', which has some nice consequences. The first part of our effort to make Psi testable is creating unit tests for most of our classes (using CppUnit), which should provide quick checks that our classes behave (and keep behaving) the way they should. However, the fact that Psi was not designed to be testable from the ground up makes this a non-trivial job, requiring quite some refactoring. This is something that will happen incrementally over time. A side effect of this refactoring will be an increase in modularity, allowing us to use different frontends (e.g. Cocoa) for the same code. The second part we're working on is creating UI tests for parts that are not automatically testable. For this, we are decoupling all our dialogs from the rest of the application, such that we can create a standalone application that allows you to toy with the dialog. This decoupling not only means that it becomes very easy to test dialogs with your own scenarios (without having to start Psi, connect to a server, ...), but also means that the dialogs become completely reusable for other applications. We still have a long way to go until every part of Psi is testable (either automatically or not), but I am very much looking forward to the day where all of our code is nicely decoupled, and we can run make check on every commit to ensure that we didn't break anything silly.

'The First 10 Prolog Programming Contests' available for downloading

2006-07-01T00:00:00+02:00

Exactly one year after we finished it, our book `The First 10 Prolog Programming Contests' is now freely downloadable. On the home page of the book, you will also find the source code of all solutions presented in the book. Below are some pictures of the 'deluxe' edition of the book, hand-made by my mom.

Dvorak: Escaping the typewriter age

2006-01-06T00:00:00+01:00

About half a year ago, I heard this story that QWERTY keyboards (and their variants) were actually designed to slow down typists (to avoid typewriters getting stuck), contrary to the Dvorak layout, which was specifically designed for speed and comfort. After having learned to count binary on my hands (yes, you can count to 1023 using only your 10 fingers!), this seemed like another fun and freaky thing to learn, and this could actually prove to be useful over time. After all, I switched from AZERTY to QWERTY before, how hard could this be ? At least I was right about it being useful. One of my students at that time was a Dvorak user, and his advise to me was to download dvorak7min (a Dvorak typing tutor), and to start practicing. I threw out QWERTY from all my computers, activated Dvorak (it seems to be installed by default on every major OS), printed the layout, and put it next to my keyboard. The tutor helped me learn the most important keys (basically the middle and the top row of the keyboard) by heart, and i went on my own from there. I would be lying if I said it was a breeze: having to think for at least a few seconds per character isn't a motivating thing if a week ago you were typing at nearly 100 words per minute. But after merely a few sleepless nights and two weeks of writing extremely short mails and slow chat sessions, frustration slowly started going away, and I started typing at an acceptable speed. Can I type considerably faster with Dvorak ? Hard to tell. What I can tell is that, only a few months after the switch, I am typing at least as fast as with the layout I have been using for all my life, which sounds promising for the future. My own QWERTY typing style involved a lot of moving my hands across the keyboard (I never learned the 'proper' blind style), whereas they hardly ever move with Dvorak, which gives me That Comfortable Feeling ®. I also notice that I make less typos while writing, and for some reason, it just feels very cool to type cd src with one hand. Of course, it's not all sunshine and roses. The biggest problem with a new layout is typing your shortcuts, since these are typically not typed while your fingers are aligned to your keyboard. This means you have to learn their position (or at least the QWERTY->Dvorak mapping) by heart. Maybe a customizable keyboard could help here (although I caught myself losing speed while looking at my keyboard after rearranging my keys to Dvorak). My conclusion: if you can afford being unproductive for a few weeks, switch to Dvorak (exclusively!). It feels good, it's more logical, it's told to alleviate RSI, and it can even serve as a topic of conversation to break the ice on parties or long train trips :)