Testing Blocker Tickets

• ...

External Projects

Hydra

Islandora

Testing Plan

git clone https://github.com/fcrepo4/fcrepo4
cd fcrepo4
git checkout <version>-RC

Sanity Builds

One-Click Run

cd fcrepo-webapp; mvn clean install -Pone-click

Manual Tests

1. Create nested containers
2. Create binary resources
3. Run fixity on binary
4. Update Properties:  Perform SPARQL-Update on container
5. Update Properties:  Perform SPARQL-Update on binary
6. Delete container
7. Delete binary
8. Use transactions
9. Create versions
10. View versions
11. Rollback versions

Database Tests

With Tomcat7 deployment, run above manual tests with alternate backend databases (Configuring JDBC Object Store)

fcr:backup/fcr:restore Functionality

These tests are designed to ensure the proper function of the 'fcr:backup/fcr:restore' features by testing them against various Fedora configurations.  The validity of the 'restore' can only be determined by crawling the repository and verifying the successful retrieval of the repository's content.

If the anticipated Fedora release is not backwards compatible with the previous version of Fedora, then the "From Fedora Version" should be the previous version.  Otherwise, it is sufficient to test the fcr:backup/fcr:restore functionality using the same version.

See: RESTful HTTP API - Backup and Restore

# Backup
curl -X POST localhost:8080/rest/fcr:backup
 
# Restore
curl -X POST -d "/path/to/backup/directory" localhost:8080/rest/fcr:restore

Resources

• These python scripts - fcrepo-testing - can be used to load RDF content and binary content to a Fedora repository and verify the integrity of the loaded resources.  Output from the load process can be used to verify the integrity of a 'restored' repository.  See the README for more info.
• This script can be used to walk your repository, failing if a non-success response is encountered.

NB: "Success" is measured not by receiving a "204 No Content" message after the 'fcr:restore' command, but by performing a GET on every resource in the repository and receiving "200 OK" messages. 

Vagrant Tests

vagrant destroy
vagrant up

Manual Tests

Same as above, plus:

1. Verify audit events are in triplestore
2. Verify resources are in triplestore
3. Verify resources are in Solr
4. Verify authorization works for the two auth-enabled configurations
5. Verify reindexing to triplestore works

4.7.0 - 4.7.2 Upgrade Testing

Tests to verify if 4.7.3 resolves errors seen with upgrading from 4.7.0 to 4.7.2

1. 4.7.2
   1. Start 4.7.0 with a new data directory
   2. Create a resource with SKOS namespace

      1. curl -X POST -d "<> a <http://www.w3.org/2004/02/skos/core#Concept>; <http://www.w3.org/2004/02/skos/core#prefLabel> 'foo' ." -H "Content-type: text/turtle" -D - http://localhost:8080/rest/

   3. Stop 4.7.0 and start 4.7.2 with the same data directory
   4. View the record from 1.b. ??
      1. Note: this did not reproduce the error for me
2. 4.7.3
   1. Repeat 1., but deploying 4.7.3 and verifying that the error does not occur

[1] Testing scripts

[2] Fedora 4 Release Test Suite