Integration Test

Test Setup

The test suite comprises a test framework and a set of test cases.
The bundle org.trialox.integrationtest.web implements the framework and currently a bundle for performance test (org.trialox.integrationtest.web.performance) is available containing 3 test cases:
Get404, GetBinaryContent, and GetRdf.

The test-framework now comes with a file pom-run.xml which contains dependencies to the bndle needed to run, this can be started using pax-run with "pax-run.sh pom-run.xml".

To run the web console to configure test cases and test framework we need to start these bundles:

  1. install http://repo.trialox.org/release/org/trialox/org.trialox.integrationtest.web/0.2/org.trialox.integrationtest.web-0.2.jar
  2. start http://repo.trialox.org/release/org/trialox/org.trialox.integrationtest.web.performance/0.2/org.trialox.integrationtest.web.performance-0.2.jar
  3. Configure smpt server and enter credentials and host
  4. Configure tests incl. enabling/disabling the tests
  5. start org.trialox.integrationtest.web

To configure the port for accessing the web console, edit conf/config.properties within felix directory.

Security Test

Admin restricted resources:

Access to admin restricted resources

  • Case 1: If an anonymous user wants to access admin restricted resources, she will be prompted to login with a 401 response
  • Case 2: If a user sends a web request with authentication header containing non-admin credentials, she will be prompted login with a 401 response
  • Case 3: If a user sends a web request with authentication header containing admin credentials, she will have access and get a 200 response

Access to user scope resources

  • Case 1: If a new user is added through a post request on /user-manager/add-user, the user must be able to access her account control panel through a get request on /account-control-panel/<username>/mainpage.
  • Case 2: User A must not be able to access the web resource /account-control-panel/<other user>/mainpage of another user.
  • Case 3: User A must not be able to start/stop/update/uninstall a bundle owned by another user using the respective post request.
  • Case 4: Admin user is able to access the web resource /account-control-panel/<any user>/mainpage of any user

Functionality Test

  • Case 1: If a new user is added through a post request on /user-manager/add-user and later retrieved using a get request on /user-manager/list, the response must contain the user newly added.
  • Case 2: If a user is deleted through a post request on /user-manager/delete-user and a list of users is later retrieved using a get request on /user-manager/list, the response must not contain the user newly deleted.
  • Case 3: If a new bundle is installed through a post request on /account-control-panel/<username>/install-bundle, then a get request on /account-control-panel/<username>/mainpage
    must return a response with the bundle listed.
  • Case 4: If a new bundle is uninstalled through a post request on /account-control-panel/<username>/uninstall-bundle, then a get request on /account-control-panel/<username>/mainpage
    must not return a response with the bundle listed.
  • Case 5: Via user manager a path prefix can be assigned to a user and all root resources of that user's bundles will be accessible with the path prefix prepended to each resource path defined in the user's bundles.
  • Case 6: A jaxrs provider of a bundle owned by User A must not be accessible by a bundle owned by User B unless A and B share the same path prefix

Performance Test

  • GET-reqeust to a URI that returns 404
  • GET-request to a URI to which binary content has been put in the init phase
  • GET-request to a resource at which a TitledContent Discobit was created during init
  • The response time to access account-control-panel of a user as a function of the number of users stored in the system graph.
  • The response time to access account-control-panel of a user as a function of the number of requests sent concurrently to the server.

Labels

 
(None)