...

You can find extra information at the related GSoC page

Quick Start

If you want to start creating tests straight away do the following:

...

There is a set of tools used by all the tests. These tools will be described in this section.

Maven

The build tool for DSpace, Maven, will also be used to run the tests. For this we will use the [Surefire|http://maven.apache.org/plugins/maven-surefire-plugin/] pluginthe Surefire plugin, which allows us to launch automatically tests included in the "test" folder of the project. We also include the Surefire-reports plugin in case you are not using a Continous Integration environment that can read the output and generate the reports.

The plugin has been configured to ignore test files whose name starts with "Abstract", that way we can create a hierarchy of classes and group common elements to various tests (like certain mocks or configuration settings) in a parent class.

Tests in Maven are usually added into into src/test, like in in src/test/java/<package> with with resources at at src/test/resources.

To run the tests execute:

...

As of JUnit 4.4, Hamcrest is included. Hamcrest is a library of matcher objects that facilitate the validation of conditions in the tests.

JMockit

[JMockit|http://code.google.com/p/jmockit/] is JMockit is a popular and powerful mocking framework. Unlike other mocking frameworks it can mock final classes and methods, static methods, constructors and other code fragments that can't be mocked using other frameworks.

JMockit 0.998 has been added to the project to provide a mocking framework to the tests.

ContiPerf

[ContiPerf|http://databene.org/contiperf.html] is ContiPerf is a lightweight testing utility that enables the user to easily leverage JUnit 4 test cases as performance tests e.g. for continuous performance testing.

The project makes use of ContiPerf 1.06.

H2

[H2|http://www.h2database.com/html/main.html] is H2 is an in-memory database that has been used used.

The project makes use of H2 version 1.2.137

Unit Tests Implementation

These are tests which test just how one object works. Typically test each method on an object for expected output in several situations. They are executed exclusively at the API level.

We can consider two types of classes when developing the unit tests: classes which have a dependency on the database and classes that don't. The classes that don't can be tested easily, using standard procedures and tests. Our main problem are classes tightly coupled with the database and its helper objects, like BitstreamFormat or the classes that inherit from DSpaceObject. To run the unit tests we need a database but we don't want to set up a standard PostgreSQL instance. Our decision is to use an in-memory database that will be used to emulate PostgreSQL.

...

To avoid the issue we have to wrap the List into a synchronized stated via [via Collections.synchronizedList|http://download.oracle. com/javase/6/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29] . This, along with a synchronized block, will ensure the code behaves as expected.

The following classes are affected by this behavior:

...