One thing that has been on my todo list for many years was writing proper unit tests for GtkTreeModelFilter (the “filter model”). The state keeping that the filter model has to do is enormously complex. Sadly, this has caused the filter model to get to a state where it was basically impossible to maintain it, a patch fixing something would almost always break something else. Getting out of such a state is generally only possible by bringing the entire thing under test. And that’s what I have done about 2 weeks ago and took a week to get the basics of the unit tests right.
The majority of the filter model code is now under test. Not only the correctness of the model’s structure is tested (are the right nodes there? Also at the correct position? Are the right nodes designated as parents? etc.), but also whether the right signals are emitted at the right moment (and with the correct details/arguments).
While writing the unit tests, 2 or 3 bugs were uncovered and also fixed. Using the unit tests I was also able to clear the long outstanding filter model bug reports from Bugzilla. Actually, being able to do that was the entire point of writing the test suite ;). When handling those reports, the usefulness of the unit tests immediately proved themselves: when patching one of the problems (with a fix that looked generally okay), one of the other tests started to fail. This regression would not have been noticed without the test suite.
Hopefully, we’ll soon get support for seeing the testing coverage (from what I heard there is a bug/patch for this in Bugzilla). Some parts of the filter model are not under test yet, most importantly the intricate reference counting of nodes. Some day I will get back to this.
What I am also hoping for is to re-use some of the concepts used for these unit tests in unit tests for other tree models. And, of course, to come up with a generic tree model tester that can be used to test custom tree models.
Many people might find such a generic tree model tester overkill and say that tree models must be much more trivial to implement. That’s something for the future really. I will promise to blog about the plans/ideas I have for GtkTreeView and friends later on. (You can imagine that a lot of ideas have been brewing while I was busy finishing my studies ;) ).
Oh by the way, currently I am doing some work on GTK+’s Quartz backend. It has suffered from some regressions after the introduction of client side windows in GTK+ and I am trying to get those under control as well as cleaning up the Quartz patch queue in Bugzilla. After that I will most probably be looking into extending/improving the CellEditable API to finally get proper acceptance/cancellation behavior.