Introduction
This document describes the technical aspects of the testing integrated into Dspace. It's divided in 3 main sections, one per each type of test added to Dspace, plus a section discussing the common tools used. It's intended to serve as a reference for the community so more test cases can be created.
Common Tools
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 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.
To run the tests execute:
mvn test
The tests will also be run during a normal Maven build cycle. To skip the tests, run Maven like:
mvn package -Dmaven.test.skip=true
By default we will disable running the tests, as they might slow the compilation cycle for developers. They can be activated using the command
mvn package -Dmaven.test.skip=true
or by commenting the corresponding profile (skiptests) in the main pom.xml file, at the root of the project.
JUnit
JUnitis a testing framework for Java applications. It was one of the first testing frameworks for Java and it's a widespread use in the community. The framework simplifies the development of unit tests and the current IDE's make even easier building those tests from existing classes and running them.
Junit 4.8.1 is added as a dependency in the parent project. The dependency needs to be propagated to the subprojects that contain tests to be run.
Unit Tests
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.
Specific Tools
Architecture
The cornerstone of our Unit Tests is a class called "AbstractUnitTest". This class contains a series of mocks and references which are necessary to run the tests in DSpace, due to the heavy dependency on Context and Database of the application. As JUnit (since 4.5) doesn't require you to extend any class, we can extend this class with our unit tests and centralise the scaffolding for the tests in one part of the code. The class is located under the package "org.dspace" in the test folder of DSpace-api.
Integration Tests
These tests work at the API level and test the interaction of components within the system. Some examples, placing an item into a collection, or creating a new metadata schema and adding some fields. Primarily these tests operate at the API level ignoring the interface components above it.
Functional Tests
These are tests which come from user-based use cases. Such as a user wants to search DSpace to find material and download a pdf. Or something more complex like a user wants to submit their thesis to DSpace and follow it through the approval process. These are stories about how users would preform tasks and cover a wide array of components within Dspace.
Thanks
This page has been created with help from Stuart Lewis, Scott Phillips and Gareth Waller. I want to thank them all for their comments. Some information has been taken from Wikipedia to make the text more complete. I'm to blame for errors in the text.
Feel free to contribute to this page!
