Testing Psi

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.