As of DSpace 7 (and above), all new code MUST come with corresponding unit or integration tests.

This guide provides an overview of how to write good unit and integration tests both for the Java (REST API) backend and the Angular (UI) frontend. 

Backend (Java / REST) Code Tests

Overview of Test Framework

Technologies used

These three modules encompass most of the current test framework:

Checklist for building good tests

Writing Integration Tests

A few quick guidelines on writing DSpace Integration Tests

Writing Unit Tests

A few quick guidelines on writing DSpace Unit Tests

Cleaning up test data

Integration Tests necessarily have to create test data to verify the code they are testing is working properly.  But, just as importantly, they must cleanup any test data they create.  Integration tests which do not cleanup after themselves often result in odd Travis CI failures. These odd failures in Travis CI may occur anytime Travis CI runs tests in a different order than your local machine and test data from an earlier test directly affects the results of a later test.

Here are three ways to ensure your test data is cleaned up properly in any Integration tests you create. They are roughly prioritized in terms of preference.

  1. Use Builders for automatic cleanup: Whenever possible, use the Builder test classes (see org.dspace.app.rest.builder.*) in "dpace-server-webapp", as these Builder classes automatically cleanup after themselves!

    // Example of creating a test Item via the ItemBuilder class
// As soon as the method using this "testItem" completes, the "testItem" will be automatically deleted
// by the AbstractBuilderCleanupUtil (which is called @After every test)
context.turnOffAuthorisationSystem();
Item testItem = ItemBuilder.createItem(context, collection);
context.restoreAuthSystemState();


  2. Cleanup after test POST or file upload: If you are testing a POST command (or file upload), you MUST cleanup the POSTed data by parsing the ID out of the response and using a Builder class for cleanup.  Our best practice is to use the following code logic.  Further examples can be found in the codebase.

    import static com.jayway.jsonpath.JsonPath.read;
import java.util.concurrent.atomic.AtomicReference;

AtomicReference<UUID> idRef = new AtomicReference<>();
try {
    // Example of a POST command to create a new Collection while logged in as the user with the given "authToken"
    getClient(authToken).perform(post("/api/core/collections")
                        ...[various params and data sent via POST]...

                        // Check the POST was successful, which means we created test content & need to clean it up!
                        .andExpect(status().isCreated())

                        // From the JSON response, read the "id" field, parse it as a UUID, and save to "idRef" local variable.
                        .andDo(result -> idRef.set(UUID.fromString(read(result.getResponse().getContentAsString(), "$.id"))));
} finally {
    // Using the CollectionBuilder, delete the Collection with UUID equal to value of idRef
    CollectionBuilder.deleteCollection(idRef.get());
}


  3. (If neither of the above are possible) "Manually" delete created data: If you create test data in the "dspace-api", unfortunately, you must manually cleanup after yourself at this time.  The "dspace-api" module doesn't have automatic cleanup utilities as described above.  Here's an example of doing so:

    // Create test data by temporarily turning off authorization
context.turnOffAuthorisationSystem();
WorkspaceItem workspaceItem = workspaceItemService.create(context, collection, true);
Item item = installItemService.installItem(context, workspaceItem);
context.restoreAuthSystemState();

[perform various tests]

// Delete the test Item created, again by temporarily turning off authorization
context.turnOffAuthorisationSystem();
itemService.delete(context, item);
context.restoreAuthSystemState();


Frontend (Angular UI) Code Tests