Dspace currently lacks unit testing, which harms the development of the platform and makes easier to reintroduce past bugs while developing. This project is a proposal to add a set of unit test classes to Dspace, based on JUnit, plus some tools that detect issues in the code so we can improve its quality. - Pere Villega |
My proposal is to do the following:
SONAR is an open source quality management platform, dedicated to continuously analyze and measure source code quality. Being an external application, my work would consist on deploy it on a server provided by Duraspace and set up the corresponding JIRA integration. This would give us an image of the coverage of the code and highlight other issues.
Maven reports don't work well in projects with several subprojects like Dspace. Some addons can't aggregate the reports properly and this makes harder to obtain this valuable information.
This has 2 components:
About the refactoring, if you run Dspace code by the testability explorer you'll notice it raises several warnings. There are classes like Context that make the testing hard. Mocks can be done and there are some ways to go around the problem, but all the effort put into that will be lost in the long term if the code is refactored to follow Demeter's Law. Also, refactoring would improve average code quality, making easier for developers to enhance Dspace.
Refactoring should solve most of the issues detected by SONAR, but there may be some other problems like duplicated code or possible sources of bugs. When possible these issues should be tackled as they will make the code more stable. This point is lower priority as the benefits on unit testing will be minor.
Generate a set of unit tests for Dspace, starting by the Dspace API and moving to other components later on.
The lack of unit testing makes easier for Dspace developers to reintroduce old bugs when doing changes to the code. It also makes harder to ensure customisations done by users are working and increases the difficulty of upgrading to new versions of the platform.
Also, following the suggestion of Graham Triggs, it will allow the usage of Contiperf (http://databene.org/contiperf/) to add performance testing to the modules.
The main aim is to apply this (all 3 points) to the API core. Once done, work would be done in the remaining time with Manakin and then other subprojects (Sword, LNI, OIA). JSPUI will be left for last, as is an interface that will disappear in the future.
The project plan will depend on the decision about refactoring the code or simply producing unit tests for it. Deployment of SONAR should be straightforward and is not mandatory (although recommendable)
It has to be decided:
Important aims are:
So far there's been some approaches to the problem. As far as we know, the following:
Next there is a table that compares these and some other approaches to the problem:
Tools |
Type |
Notes |
|---|---|---|
JUnit + JMock |
Unit Testing |
Dspace is tightly integrated with the database (see notes above) which makes this work harder |
JUnit + HTMLUnit |
Functional |
Uses a embedded webserver to run Dspace and runs the tests, using ant, against this instance |
Selenium |
Functional |
Can be run against any running Dspace instance and using several browsers |
JUnit + ContiPerf |
Unit Testing + Performance Testing |
Suffers from the same issues as other Unit Tests, tight integration with database |
As we see we have two main approaches:
Both would benefit DSpace, as unit testing would ensure code quality while functional testing would ensure the application behaves as expected with standard usage.