KWin is one of the oldest KDE applications still in active development without having been rewritten from scratch. Development of KWin started in 1999 for KDE 2, but some parts of KWin even date back to KWM from KDE 1 times. The main software design of the Window Manager component hasn’t changed that much since the initial commit – there is a “Workspace” which manages “Clients”.

Personally I find it very interesting to see such old parts of the code and software design. If we think about it we realize that the development started just a few years after the Gang of Four published their book about Design Patterns. Also development-methods like Test-Driven-Development and unit testing got described around that time for the first time.

Given that it is not surprising that when development to KWin started unit tests were not added to the code base. At the time when QtTestLib got introduced KWin had already been in development for six years and not necessarily a code base which could easily be unit tested. Some classes inside KWin had turned into a size which makes it hardly possible to mock the required functionality.

In order to use QtTestLib the port to Qt 4 had been required. At the same time compositing support got added to KWin – an area which mostly depends on visual representation and which is hardly unit testable at all. It is quite understandable that at that time nobody considered it worth the effort to add unit tests to the existing code base.

Also it’s quite difficult to start with unit testing if you have been developing an application for a decade without unit tests. You might not see the need for the tests and in general we can say that adding the first test is the most difficult. For an application like KWin which highly requires interaction with an external application (X-Server) it is quite clear that one might consider it as impossible to unit test KWin at all.

Personally I believe in the usefulness of unit tests especially during bug fixing. So I think that each bug fix should come with a unit test illustrating the problem. Unfortunately there is still a long way to go before establishing such a policy in KWin due to the difficulties in performing unit tests for a window manager.

Nevertheless even KWin has parts which can be unit tested. And recently I added the very first test to KWin. In 4.8 the KConfig Update Script had a small bug which resulted in very rare cases in an incorrectly migrated configuration. When adding the KConfig Update Script for 4.9 I wanted to make sure that all possible upgrade paths are considered and therefore added the very first unit test for the KConfig Update Script.

With that the most important first step is done: the KWin source tree contains a tests directory and now it becomes easier to add further QtTestLib based tests. So when I recently started to refactor some code which can be unit tested I decided to go for adding a unit test together with the new implementation. And I must say it turned very useful – some minor bugs I added, could be easily spotted without any code investigations. Just the way I like it.

Unfortunately unit testing with QtTestLib allows only to test a very small portion of KWin. Anything interacting with the X-Server cannot be tested that way. Many parts require to be a window manager and as the situation is you can only have one window manager running. So a unit test would need to be a window manager and would interfere with the working system – nothing we want from a unit test.

Given that we would have to basically start the full-blown KWin to perform tests which interact with the X-Server. Unit tests are out of scope and only integration tests seem feasible. But in fact running tests against a running KWin cannot work as it would interact with the running system. E.g. how to test that a window is set to keep above if there is a window rule that forces the same window to keep below.

This is a difficult topic to solve. We basically need a dedicated testing framework which starts a (nested) X-Server, starts KWin, performs a test and shuts down both KWin and the X-Server. A framework which is decoupled from the running system.

I’m currently supervising a Bachelor Thesis to evaluate the possibilities of such a framework and to implement a prototype tailored towards the needs of KWin. The current ideas look very promising and are based on KWin’s scripting capabilities by injecting KWin scripts to test certain functionality. I’m looking forward to this implementation as I hope that it will make our life easier – even if it will not be possible to run the tests on a Jenkins installation.

Also I really like the idea of working together with students. We already do that during GSoC, but there are so much more possibilities for FLOSS to work together with academics. Being it Bachelor Thesis or just seminar papers: FLOSS source code is a great area to work together with real world software and not just a demo application as it is so often the case at Universities.