These python tests are meant to be run against a standalone Fedora 4 instance.
This will create, update and delete resources in the repository. So you may not want to use it on a production instance.
Also, this is doing a cursory test. It does some verification of RDF, and patches are always welcome.
Note: in order to test authorization, please first verify that your Fedora repository in configured to use authorization.
Check the repository.json
in use, and verify that the security
block contains a providers
list such as:
"providers" : [
{ "classname" : "org.fcrepo.auth.common.ServletContainerAuthenticationProvider" }
]
This has been designed for Python 3, but should be backwards compatible.
To install:
-
Clone this directory
-
In the fcrepo4-tests directory run
pip install -r requirements.txt
for python 2.*pip3 install -r requirements.txt
for python 3.*
to install dependencies
-
Run the tests with the config file switch (
-c
), ie../testrunner.py -c config.yml.example
The testrunner.py
has many configuration options, but essentially it needs to know.
- The base URL of your Fedora
- The Admin username
- The Admin password
- A second user's name
- A second user's password
- A third user's name
- A third user's password
The config.yml.example
has an example setup for a default Fedora running with mvn jetty:run
To see all options run
./testrunner.py --help
You can store multiple configurations in one config file, then you can use the -n|--site_name
option to choose a
different configuration.
For example, with this config.yml
default:
baseurl: http://localhost:8080/rest
admin_user: fedoraAdmin
admin_password: fedoraAdmin
user1: testuser
password1: testpass
user2: testuser2
password2: testpass
second_site:
baseurl: http://someserver:8080/fcrepo/rest
admin_user: theBoss
admin_password: bossesPW
user1: user1
password1: password1
user2: user2
password2: password2
To use the second_site
configuration, simply start the testrunner with
./testrunner.py -c config.yml -n second_site
If a configuration cannot be found or the -n|--site_name
argument is not present we default to the default
profile.
You can also choose to run only a subset of all tests using the -t|--tests
argument. It accepts a comma separated list
of the following values which indicate which tests to run.
authz
- Authorization testsbasic
- Basic interaction testssparql
- Sparql operation testsrdf
- RDF serialization testsversion
- Versioning teststransaction
- Transcation testsfixity
- Binary fixity tests
Without this parameter all the above tests will be run.
To run only the authz
and sparql
tests you would execute:
./testrunner.py -c config.yml -t authz,sparql
- Create a container called cover
- Patch it to a pcdm:Object
- Verify no ACL exists
- Add an ACL to cover
- Create a container inside cover called files
- Verify Anonymous can't access cover
- Verify admin user can access cover
- Verify regular user 1 can access cover
- Verify regular user 2 can't access cover
- Create a container
- Create a container inside the container from step 1
- Create a binary inside the container from step 2
- Delete the binary
- Delete the container from step 1
- Create a LDP Basic container
- Validate the correct Link header type
- Create a LDP Direct container
- Validate the correct Link header type
- Create a LDP Indirect container
- Validate the correct Link header type
- Create a binary resource
- Get a fixity result for that resource
- Compare that the SHA-1 hash matches the expected value
- Create a container
- Set the dc:title of the container with a Patch request
- Update the dc:title of the container with a Patch request
- Verify the title
- Create a binary
- Set the dc:title of the binary with a Patch request
- Update the dc:title of the binary with a Patch request
- Verify the title
- Create a container
- Update the title to text with Unicode characters
- Verify the title
- Create a transaction
- Get the status of the transaction
- Create a container in the transaction
- Verify the container is available in the transaction
- Verify the container is not available outside the transaction
- Commit the transaction
- Verify the container is now available outside the transaction
- Create a second transaction
- Create a container in the transaction
- Verify the container is available in the transaction
- Verify the container is not available outside the transaction
- Rollback the transaction
- Verify the container is still not available outside the transaction
- Create a container
- Check for versions of the container
- Create a version of the container with existing body
- Create a version of the container with specific datetime
- Try to create a version of the container with the same datetime
- Update the container with a PATCH request
- Try to PATCH the Memento
- Create another version of the container with existing body
- Count number of versions
- Delete a version
- Verify deletion
- Count number of versions again
- Create Memento at deleted memento's datetime
- Verify Memento exists
- Create a pcdm:Object
- Create a pcdm:Collection
- Create an indirect container "members" inside the pcdm:Collection
- Create a proxy object for the pcdm:Object inside the members indirectContainer
- Verify that the pcdm:Collection has the memberRelation property added pointing to the pcdm:Object