The Texas Digital Library has been focusing on testability for our projects. Since DSpace is related too or part of most of our projects we’ve been looking for a way to increase DSpace’s testability. Traditionally this would mean adding unit tests and integration tests. However as DSpace currently stands is hard to break it up into individual components that can be tested in isolation. You’ll quickly find that writing tests for DSpace pull in the entire system, plus databases, and a file system. To address this problem we’ve created a simple framework for adding both integration tests and functional tests which improve the reliability of our projects. I’m interested to see if this is something the greater DSpace community would be interested in?

The goals of our project were to create a mechanism where we could run complete functional tests. Functional tests evaluate the entire system as the end user would use it, so think of it as opening a web browser and evaluating the output – but completely automated. They test everything all together. Ideal it would be better to test each component individual, but this is in practical for DSpace for two reasons 1) DSpace is highly integrated and nearly impossible to separate from the database and file systems, 2) Creating unit test for all of DSpace is very time consuming it is simpler to write a few functional tests that cover a wide set of features over the whole application. It gets you to a point where you can reliably verify the software quicker. If you’re working on unit tests for DSpace please do not let this stand in your way.

The main concept is to script the install of a test DSpace, with a full configuration and setup. Then we start DSpace in an embedded webserver and then run through several scenarios just as a normal user would. This tests the whole application, using a database, a file system, and a full build. The ant script where you normally run “ant fresh_install” has a new target “ant test”. You pass it a few parameters such as what database to use. The script will then run through a fresh install of DSpace into a local /test directory, setup some communities and collections, and import some basic items. Then JUnit-based tests are run against the embedded webserver using HtmlUnit to simplify verifying the HTML output.

Here is how to run it. After compiling using a “mvn package”, cd into target/dspace-*-build.dir/ directory. Then run “ant test” you may need to pass it some parameters as listed below. Each parameter has a default so if you configure you’re database connections the same way then it can be as simple as running “ant test” without any parameters.

 -Dtest.db.driver="org.postgresql.Driver"
 -Dtest.db.url="jdbc:postgresql://localhost:5432/dspacetest"
 -Dtest.db.username="dspacetest"
 -Dtest.db.password="dspacetest"
 -Dtest.dspace.dir=”./test/"
 -Dtest.config=”./test/config/dspace.cfg"

We’ve used this approach rather successfully for two of our DSpace-based projects here at TDL: an ETD submission system called vireo, and a learning object repository. These projects haven’t moved to 1.6 yet, but I do have a patch available for DSpace 1.5.2. Most of the test cases we’ve created so far are specific to the project we’re working on. However the patch includes 4 manakin tests, which are really just an example of how tests work within this framework.

Download the patch: DSpace-1.5.2-FunctionalTest-V2.patch

The question is, is this something that the DSpace community would like? You can follow the discussion of this topic on the dspace-devel mailing list.

Update 4/8/2010: The original patch was missing a class, that has been corrected.