Unit-testing of DSpace requires a good deal of set-up. dspace-api has a nice testing framework, but it can't be used by other projects because they can't access the DSpace-specific test scaffolding that is contained in dspace-api as test-scoped classes.
Also, the framework depends on copying a suitably-populated DSpace target directory tree. There is a separate test version of this tree which might not be maintained in timely fashion when the installation version is updated. We should always be testing with the latest configuration and external document files.
I think this suggests two additional artifacts which can then be test-scoped dependencies of any project wishing to use the framework.
We need an archive (probably Zip) of the config and etc portions of the DSpace target tree, suitably filtered for testing. These files reside in the dspace subproject and would need to be packaged there or in dspace-parent.
We need a JAR of the common test scaffolding classes and their configuration data. These reside in dspace-api and would be packaged there. (I think that eventually we might want to pull the framework out into its own project, which would simplify the build process and our thinking.)