Testing Blocker Tickets
|fcrepo4||mvn clean install|
|fcrepo4||mvn clean install||mac|
|fcrepo4||mvn clean install||windows|
cd fcrepo-webapp; mvn clean install -Pone-click
|java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar||Linux|
|java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar||Mac|
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar
All of the below should take place in the HTML UI and non-vagrant tests should run against fcrepo-webapp-plus.
- Create nested containers
- Create binary resources
- Run fixity on binary
- Update Properties: Perform SPARQL-Update on container
- Update Properties: Perform SPARQL-Update on binary
- Delete container
- Delete binary
- Use transactions
- Create versions
- View versions
- Rollback versions
With Tomcat7 deployment, run above manual tests with alternate backend databases (Configuring JDBC Object Store)
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.
# Backup curl -X POST localhost:8080/rest/fcr:backup # Restore curl -X POST -d "/path/to/backup/directory" localhost:8080/rest/fcr:restore
- 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.
Size of Backup (du -h .)
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.
|Test steps||Tested by||Success?||Notes|
Same as above, plus:
- Verify audit events are in triplestore
- Verify resources are in triplestore
- Verify resources are in Solr
- Verify authorization works for the two auth-enabled configurations
- Verify reindexing to triplestore works
Backwards Compatibility Tests
- Start 4.7.0 one-click
- Load sample datasets via /fcr:restore
- Run test scripts on 4.7.0
- Stop 4.7.0
- Start RC one-click
- Run test scripts on RC
- ReStart RC
- Run test scripts on RC
|Tested by||Success RC2||Notes|
 Testing scripts