Commit 7c2275d0 authored by Jorge Moratinos's avatar Jorge Moratinos
Browse files

Merge branch 'OCF-Doc54-add-documentation-for-the-new-tests-created' into 'develop' 

Resolve "Add documentation for the new tests created"

Closes #54

See merge request !59
parents ca1fb7f7 eae8adf9

doc/testing/testplan/api_invoker_management/README.md

+82 −0
Original line number Diff line number Diff line
@@ -300,6 +300,88 @@ At this documentation you will have all information and related files and exampl 
     2. notificationDestination on response must contain the new value





## Test Case 8: Onboard invoker without supported_features



**Test ID**: ***capif_api_invoker_management-8***



**Description**:



  This test will try to register new Network App at CAPIF Core without providing `suppFeat` in request body



**Pre-Conditions**:



  * Network App was not registered previously

  * Network App was not onboarded previously

  * ***Preconditions: The administrator must have previously registered the User.***



**Execution Steps**:



  1. Retrieve access_token by User from register

  2. Onboard Invoker at CCF without providing `suppFeat` field in request body



**Information of Test**:



  1. Create public and private key at invoker



  2. Retrieve access_token by User:



    * Send **GET** to **https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth**

      * Include basic Auth Header with Admin user/password

    * Retrieve **access_token** and the urls needed for next requests from response body [user_getauth_response_body_example]



  3. Onboard Invoker:

     * Send **POST** to **https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers**

     * Reference Request Body: [invoker onboarding body] without `supported_features` field in body

     * "onboardingInformation"->"apiInvokerPublicKey": must contain public key generated by Invoker.

     * Send in Authorization Header the Bearer access_token obtained previously (Authorization:Bearer ${access_token})



**Expected Result**:



  1. Response to Onboard request must accomplish:

     1. **400 Bad Request**

     2. Response Body must give details about the missing `supported_features` field in request body





## Test Case 9: Update Onboarded Network App without supported_features



**Test ID**: ***capif_api_invoker_management-9***



**Description**:



  This test will try to update information of previous onboard Network App at CAPIF Core, but without sending `supported_features` in request body.



**Pre-Conditions**:



  * Network App was registered previously

  * Network App was onboarded previously with {onboardingId}



**Execution Steps**:



  1. Register Invoker at CCF

  2. Onboard Invoker at CCF

  3. Store signed Certificate

  4. Update Onboarding Information at CCF, without `supported_features` field in request body



**Information of Test**:



  1. Perform [Invoker Onboarding]



  2. Update information of previously onboarded Invoker:

     * Send **PUT** to **https://{CAPIF_HOSTNAME}/api-invoker-management/v1/onboardedInvokers/{onboardingId}**

     * Reference Request Body is: [put invoker onboarding body], but without sending `supported_features` in request body



**Expected Result**:



  1. Response to Onboard request must accomplish:

     1. **400 Bad Request**

     2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:

        * apiInvokerId

        * onboardingInformation->apiInvokerCertificate must contain the public key signed.

     3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**

  2. Response to Update Request (PUT) without providing `supported_features` in request body must contain:

     1. **400 Bad Request** response.

     2. Response Body must give details about the missing `supported_features` field in request body





[invoker onboarding body]: ./invoker_details_post_example.json  "API Invoker Request"

[user_getauth_response_body_example]: ../common_operations/user_getauth_response_body_example.json  "User GetAuth response Body Example"

doc/testing/testplan/api_provider_management/README.md

+95 −0
Original line number Diff line number Diff line
@@ -400,6 +400,101 @@ At this documentation you will have all information and related files and exampl 
        * cause with message "Not found registrations to Send **THIS** api provider details".





## Test Case 9: Onboard provider without supported_features



**Test ID**: ***capif_api_provider_management-9***



**Description**:



  This test case will check that a provider cannot be registered without providing `suppFeat` field in request body



**Pre-Conditions**:



  * Provider is pre-authorised (has valid certificate from CAPIF Authority)



**Execution Steps**:



  1. Create private and public key for provider and each function to register.

  2. Register Provider without sending `suppFeat` field inside request body.



**Information of Test**:



  1. Create public and private key at provider for provider itself and each function (apf, aef and amf)



  2. Retrieve access_token by User:



    * Send **GET** to **https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth**

      * Include basic Auth Header with Admin user/password

    * Retrieve **access_token** and the urls needed for next requests from response body [user_getauth_response_body_example]



  3. Register Provider:



     * Send **POST** **https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations**

     * body [provider request body] without suppFeat

     * Authentication Bearer with access_token

     * Store each cert in a file with according name.



**Expected Result**:



  1. Register Provider at Provider Management:

     1. **400 Bad Request** response.

     2. body returned has to give details about the missing `suppFeat` field

     5. Location Header must contain the new resource URL **{apiRoot}/api-provider-management/v1/registrations/{registrationId}**





## Test Case 10: Update Registered Api Provider  



**Test ID**: ***capif_api_provider_management-10***



**Description**:



  This test case will check that a Registered Api Provider cannot be updated if `suppFeat` field is missing in request body



**Pre-Conditions**:



  * Api Provider was registered previously and there is a {registerId} for his Api Provider in the DB



**Execution Steps**:



  1. Create private and public key for provider and each function to register.

  2. Register Provider

  3. Update Provider without providing `suppFeat` in request body



**Information of Test**:



  1. Create public and private key at provider for provider itself and each function (apf, aef and amf)

  2. Retrieve access_token by User:



    * Send **GET** to **https://${CAPIF_REGISTER}:${CAPIF_REGISTER_PORT}/getauth**

      * Include basic Auth Header with Admin user/password

    * Retrieve **access_token** and the urls needed for next requests from response body [user_getauth_response_body_example]



  3. Register Provider:



     * Send **POST** **https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations**

     * body [provider request body]

     * Authentication Bearer with access_token

     * Get Resource URL from Location



  4. Update Provider:



     * Send **PUT** to Resource URL returned at registration **https://{CAPIF_HOSTNAME}/api-provider-management/v1/registrations/{registrationId}**

     * body [provider request body] with apiProvDomInfo set to ROBOT_TESTING_MOD and without providing `suppFeat` field

     * Use AMF Certificate.



**Expected Result**:



  1. Register Provider:

     1. **201 Created** response.

     2. body returned must accomplish **APIProviderEnrolmentDetails** data structure.

     3. Location Header must contain the new resource URL **{apiRoot}/api-provider-management/v1/registrations/{registrationId}**





  2. Update Provider:

     1. **400 Bad Request** response.

     2. body returned has to give details about the missing `suppFeat` field





[provider request body]: ./provider_details_post_example.json  "API Provider Enrolment Request"



[provider request patch body]: ./provider_details_enrolment_details_patch_example.json  "API Provider Enrolment Patch Request"