Since Andrew Moore has already done some great work on building up Koha’s test suite for C4 classes, I thought I’d talk about some of the ways that we as developers can add to his work.  I know in my recent development work, I have been trying to add tests where I can.

There’s a good overview on running the test suite, or specific test cases, on the Koha wiki.  What I’d like to talk about are a couple of reasons why we should be writing test cases whenever possible.

Adding more tests to our test suite can be beneficial in a number of ways.  As a new developer to Koha, writing test cases has really helped me understand what’s going on behind the scenes.  For me, writing the test case before I start working is the best way to figure out what the code is doing now, and also what it should be doing in the case of bug fixes, or what I want it to do in the case of adding new features.  That process, generally called Test Driven Developement, or TDD for short, can be awkward for many developers that have never done it before.  My main point though is not to get everyone drinking the TDD Kool-Aid, so the benefits of TDD can wait.  Though as someone that had to re-learn how to develop using TDD, I can attest to the changes one has to overcome. Test cases can be easily written both before and after code changes, so let’s get back to the topic at hand.

Another benefit of test cases is that it allows for a more rapid refactoring of the code base.  Even in my short time with LibLime and working on Koha, many of us on the Koha IRC or mailing lists have discussed ways to improve the code base, like converting to DBIx, mod_perl, or just adding warnings to classes. The more robust and complete our test cases become, the higher the confidence all of us can have in changing the code by running the test suite (or class) after we make changes.  Part of the problem in making these large-scale changes though, is the concern for what functionality we would break or alter.  Having test cases that validate behavior both before and after changes are made can be a huge benefit to successful deployment.

Of course, one of the problems in writing test cases is the fact that as a developer, often times you write as much (or more) in the test cases than you do in the actual code change itself!  While that is often true, most of the time this can be attributed to initial setup cost as once tests are written, they can be used over and over again.  An example is the work I am doing on enhancing the fines portion of Koha.  As I write test cases, I am also able to use the same test cases I wrote for the C4::Members class in another branch, making C4::Members work with DBIx::Class.  As these test cases get merged into the Koha public repository, others can also use these tests to validate still more changes to C4::Members.  So I spent some time initially doing more code than I planned, but in the long term, the benefits quickly repay the initial cost spent in code and time.

While it is often helpful to still test code changes through the browser, having test cases also allow us as developers to isolate problems faster. If you can verify that methods are inserting/updating records correctly via test cases, you save valuable time on support by then focusing on Javascript or HTML errors.  Code also tends to become more maintainable as ‘do-all’ methods get broken up into smaller methods that are easier to test.  In my past experience, while there can doubt as to the quality of the tests available, or concerns that existing test cases are not reliably structured, there can be no doubt that everyone agreed that the existence of tests provided a more stable end product. With the community’s help, hopefully we can all witness that first-hand here as well.

Lately I’ve been looking into use Selenium and JsUnit to test Biblios. Selenium is designed to allow functional testing of web applications, while JsUnit is a unit test framework for Javascript applications.

There are some challenges to using each of these testing tools because of Biblios’ architecture and heavy use of AJAX. One way to use Selenium is termed Selenium Remote Control. This sets up a proxy server and starts a browser instance which connects to the proxy server; the proxy server forwards requests to the site being tested and reports back to the test script the results. One problem for Biblios in this approach is that the browser instance run by Selenium Remote Control must have the Google Gears extension installed in order to work. This takes a little work to set up, or a custom profile in the case of Firefox.

A challenge in using JsUnit is that JsUnit provides no way to wait until specified conditions occur before executing a test. This is necessary in Biblios because certain tests cannot be run until the application is fully loaded, which happens through the use of AJAX calls after the html/js/css of the index.html page is loaded. So JsUnit starts running its tests before Biblios is really ready for them. Luckily, Selenium does provide a means of waiting for specified conditions before executing tests.

Still another challenge in testing Biblios is that Biblios’ html is nearly entirely generated by the ExtJS javascript framework. This makes identifying elements to test a challenge because in many cases the html elements have no systematic id attribute to rely upon.