From a1d48aee813ce91c93247d13ffbbe4481c3b1e8b Mon Sep 17 00:00:00 2001 From: "claudia.carballo" Date: Fri, 13 Feb 2026 12:47:39 +0100 Subject: [PATCH 1/2] docs: add test plan for visibility control feature --- .../testplan/visibility_control/README.md | 186 +++++++++++++++--- 1 file changed, 160 insertions(+), 26 deletions(-) diff --git a/doc/testing/testplan/visibility_control/README.md b/doc/testing/testplan/visibility_control/README.md index 60ca5db9..e050bd07 100644 --- a/doc/testing/testplan/visibility_control/README.md +++ b/doc/testing/testplan/visibility_control/README.md @@ -1,65 +1,199 @@ # Test Plan for Visibility Control Feature At this documentation you will have all information and related files and examples of test plan for this feature. +## Feature Description +The **Visibility Control API** is a helper service within OpenCAPIF, allowing API Providers and administrators to define fine-grained rules that determine whether specific APIs can be discovered and consumed by API Invokers. + +This test plan validates the lifecycle of the visibility control rules, ensuring that authentication/authorization logic and mandatory parameters are correctly enforced. + --- + ## Test Case 1: Get Visibility Control Rules as Superadmin -**Test ID**: ***visibility_control-1*** +**Test ID**: `visibility_control-1` **Description**: - - This test case will check if a ... +This test case verifies that the Superadmin can retrieve the registered rules. In this case, the response is an empty registry because no rules have been provisioned. It validates the basic connectivity and authentication flow for administrative roles. **Pre-Conditions**: - - * Network App was registered previously - * .... +* The CAPIF helper service is deployed and reachable. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. +* The database is in a clean state (no rules existing). **Execution Steps**: +1. Authenticate as Superadmin. +2. Send a **GET** request to `{apiRoot}/helper/visibility-control/rules`. +3. Inspect the JSON response body. - 1. Register Provider at CCF, store certificates. - 2. ... +**Expected Result**: +* **Status**: 200 OK. +* **Body**: Returns a JSON object with a `rules` array. The length of this array must be **0**. -**Information of Test**: +--- - 1. Perform [Provider Registration] and [Invoker Onboarding] - 2. ... +## Test Case 2: Create Visibility Control Rule with Invalid Dates as Superadmin -**Expected Result**: +**Test ID**: `visibility_control-2` - 1. ... +**Description**: +This test case validates the API's logic regarding time-range consistency. A visibility rule must have a logical duration; therefore, the service must reject any attempt to create a rule where the expiration date occurs before the start date. + +**Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. + +**Execution Steps**: +1. Authenticate as Superadmin. +2. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules`. +3. Use a payload where `startsAt` is later than `endsAt` (e.g., Starts: 2026, Ends: 2025). + +**Expected Result**: +* **Status**: 400 Bad Request. +* **Body**: Must contain a `ProblemDetails` object with the `detail` field specifying "endsAt must be later than startsAt". --- -## Test Case 2: Create Visibility Control Rule Invalid Dates as Superadmin -**Test ID**: ***visibility_control-2*** +## Test Case 3: Create Visibility Control Rule + +**Test ID**: `visibility_control-3` **Description**: +This test verifies that the Superadmin can create a rule, obtain its information, and successfully remove it. + +**Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. +* A valid `RuleCreateRequest` payload including the mandatory `providerSelector` and `userName`. - This test case will check if a ... +**Execution Steps**: +1. Authenticate as Superadmin. +2. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules`. +3. Send a **GET** request to `{apiRoot}/helper/visibility-control/rules`. +4. **DELETE** the specific rule using the captured `ruleId`. +5. **GET** the rules list again to verify the count returns to zero. + +**Expected Result**: +* Creation: **201 Created** (Body contains the generated `ruleId`). +* Listing: **200 OK** (List length is 1). +* Deletion: **204 No Content**. + +--- + +## Test Case 4: Get Visibility Control Rule by AMF Provider + +**Test ID**: `visibility_control-4` + +**Description**: +This test case validates that an AMF Provider can list rules and that the system correctly maps the Provider's certificate (CN) to their registered identity to filter the results. **Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* A Provider has been registered and onboarded at CCF. +* The Provider possesses a valid certificate (in this case AMF certificate). + +**Execution Steps**: +1. Authenticate using the **AMF Provider Certificate**. +2. Send a **GET** request to `{apiRoot}/helper/visibility-control/rules`. + +**Expected Result**: +* **Status**: 200 OK. +* **Validation**: The response body must only contain rules where the requester is the owner (`userName`). + +--- + +## Test Case 5: Create Visibility Control Rule by AMF Provider and DELETE by superadmin - * Network App was registered previously - * .... +**Test ID**: `visibility_control-5` + +**Description**: +This test validates the roles and permissions of Superadmin and Providers to create, delete and obtain rules. + +**Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* A Provider has been registered and onboarded at CCF. +* The Provider possesses a valid certificate (in this case AMF certificate). +* Superadmin has administrative access. **Execution Steps**: +1. AMF Provider creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. Superadmin sends a **GET** request to `{apiRoot}/helper/visibility-control/rules`. +3. Superadmin sends a **DELETE** request for that `ruleId`. - 1. Register Provider at CCF, store certificates. - 2. ... +**Expected Result**: +* Provider rule Creation: **201 Created**. +* Superadmin Get: **200 OK**. +* Superadmin Deletion: **204 No Content**. +* **Validation**: The rule is successfully removed from the database. -**Information of Test**: +--- + +## Test Case 6: Create and Delete Visibility Control Rule by AMF Provider - 1. Perform [Provider Registration] and [Invoker Onboarding] - 2. ... +**Test ID**: `visibility_control-6` + +**Description**: +This test validates tha the Providers can create, delete and obtain rules, ensuring that the identity-based authorization logic correctly identifies the owner of a resource and allows them to delete it without requiring Superadmin intervention. + +**Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* A Provider has been registered and onboarded at CCF. +* The Provider possesses a valid certificate (in this case AMF certificate). + +**Execution Steps**: +1. AMF Provider creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. AMF Provider **DELETE** the same rule using the same provider identity and the `ruleId`. **Expected Result**: +* Status: **204 No Content**. +* **Validation**: Subsequent list requests by the provider return an empty set. + +--- + +## Test Case 7: Create Update and Delete Visibility Control Rule by AMF Provider + +**Test ID**: `visibility_control-7` - 1. ... +**Description**: +This test validates the `PATCH` implementation. It ensures that Providers can perform partial updates to their rules and that the system correctly updates metadata like `updatedAt`. + +**Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* A Provider has been registered and onboarded at CCF. +* The Provider possesses a valid certificate (in this case AMF certificate). + +**Execution Steps**: +1. AMF Provider creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. Send a **PATCH** request to `{apiRoot}/helper/visibility-control/rules/{ruleId}`. +3. Payload: Change `default_access` from "ALLOW" to "DENY". +4. Verify the response contains the updated field. +5. AMF Provider **DELETE** the same rule using the same provider identity and the `ruleId`. + +**Expected Result**: +* **Status**: 200 OK. +* **Body**: Returns the updated `Rule` object showing the new `default_access` value and a refreshed `updatedAt` timestamp, and finally the rule is succesfully removed. --- +## Test Case 8: Create and Get Specific Visibility Control Rule - [Invoker Onboarding]: ../common_operations/README.md#onboard-an-invoker "Invoker Onboarding" - [Provider Registration]: ../common_operations/README.md#register-a-provider "Provider Registration" +**Test ID**: `visibility_control-8` + +**Description**: +This test verifies the direct resource addressing logic and the error reporting. + +**Pre-Conditions**: +* The CAPIF helper service is deployed and reachable. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. + +**Execution Steps**: +1. Superadmin creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. **GET** the specific resource via `{apiRoot}/helper/visibility-control/rules/{ruleId}`. +3. **DELETE** the resource. +4. Perform the same **GET** request as in step 2. + +**Expected Result**: +* Step 2: **200 OK** (Returns the specific rule object). +* Step 4: **404 Not Found** (Ensures the resource no longer exists in the registry). + +--- -- GitLab From 3d8f346343111722cfc1cc39ce3db11ad48ddf0c Mon Sep 17 00:00:00 2001 From: "claudia.carballo" Date: Fri, 13 Feb 2026 12:52:26 +0100 Subject: [PATCH 2/2] docs: standardize formatting and bold styles in visibility control test plan --- .../testplan/visibility_control/README.md | 114 +++++++++--------- 1 file changed, 56 insertions(+), 58 deletions(-) diff --git a/doc/testing/testplan/visibility_control/README.md b/doc/testing/testplan/visibility_control/README.md index e050bd07..d07a7e8e 100644 --- a/doc/testing/testplan/visibility_control/README.md +++ b/doc/testing/testplan/visibility_control/README.md @@ -2,9 +2,9 @@ At this documentation you will have all information and related files and examples of test plan for this feature. ## Feature Description -The **Visibility Control API** is a helper service within OpenCAPIF, allowing API Providers and administrators to define fine-grained rules that determine whether specific APIs can be discovered and consumed by API Invokers. +The **Visibility Control API** is a helper service within **OpenCAPIF**, allowing API Providers and administrators to define fine-grained rules that determine whether specific APIs can be discovered and consumed by API Invokers. -This test plan validates the lifecycle of the visibility control rules, ensuring that authentication/authorization logic and mandatory parameters are correctly enforced. +This test plan validates the lifecycle of the visibility control rules, ensuring that authentication, authorization logic, and mandatory parameters are correctly enforced. --- @@ -13,21 +13,21 @@ This test plan validates the lifecycle of the visibility control rules, ensuring **Test ID**: `visibility_control-1` **Description**: -This test case verifies that the Superadmin can retrieve the registered rules. In this case, the response is an empty registry because no rules have been provisioned. It validates the basic connectivity and authentication flow for administrative roles. +This test case verifies that the **Superadmin** can retrieve the registered rules. In this case, the response is an empty registry because no rules have been provisioned. It validates the basic connectivity and authentication flow for administrative roles. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. +* The **CAPIF** helper service is deployed and reachable. * Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. * The database is in a clean state (no rules existing). **Execution Steps**: -1. Authenticate as Superadmin. +1. Authenticate as **Superadmin**. 2. Send a **GET** request to `{apiRoot}/helper/visibility-control/rules`. -3. Inspect the JSON response body. +3. Inspect the **JSON** response body. **Expected Result**: -* **Status**: 200 OK. -* **Body**: Returns a JSON object with a `rules` array. The length of this array must be **0**. +* **Status**: **200 OK**. +* **Body**: Returns a **JSON** object with a `rules` array. The length of this array must be **0**. --- @@ -39,17 +39,17 @@ This test case verifies that the Superadmin can retrieve the registered rules. I This test case validates the API's logic regarding time-range consistency. A visibility rule must have a logical duration; therefore, the service must reject any attempt to create a rule where the expiration date occurs before the start date. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. +* The **CAPIF** helper service is deployed and reachable. * Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. **Execution Steps**: -1. Authenticate as Superadmin. +1. Authenticate as **Superadmin**. 2. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules`. -3. Use a payload where `startsAt` is later than `endsAt` (e.g., Starts: 2026, Ends: 2025). +3. Use a payload where `startsAt` is later than `endsAt` (e.g., Starts: `2026`, Ends: `2025`). **Expected Result**: -* **Status**: 400 Bad Request. -* **Body**: Must contain a `ProblemDetails` object with the `detail` field specifying "endsAt must be later than startsAt". +* **Status**: **400 Bad Request**. +* **Body**: Must contain a `ProblemDetails` object with the `detail` field specifying **"endsAt must be later than startsAt"**. --- @@ -58,24 +58,24 @@ This test case validates the API's logic regarding time-range consistency. A vis **Test ID**: `visibility_control-3` **Description**: -This test verifies that the Superadmin can create a rule, obtain its information, and successfully remove it. +This test verifies that the **Superadmin** can create a rule, obtain its information, and successfully remove it. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. +* The **CAPIF** helper service is deployed and reachable. * Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. * A valid `RuleCreateRequest` payload including the mandatory `providerSelector` and `userName`. **Execution Steps**: -1. Authenticate as Superadmin. +1. Authenticate as **Superadmin**. 2. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules`. 3. Send a **GET** request to `{apiRoot}/helper/visibility-control/rules`. 4. **DELETE** the specific rule using the captured `ruleId`. 5. **GET** the rules list again to verify the count returns to zero. **Expected Result**: -* Creation: **201 Created** (Body contains the generated `ruleId`). -* Listing: **200 OK** (List length is 1). -* Deletion: **204 No Content**. +* **Creation**: **201 Created** (Body contains the generated `ruleId`). +* **Listing**: **200 OK** (List length is **1**). +* **Deletion**: **204 No Content**. --- @@ -84,19 +84,19 @@ This test verifies that the Superadmin can create a rule, obtain its information **Test ID**: `visibility_control-4` **Description**: -This test case validates that an AMF Provider can list rules and that the system correctly maps the Provider's certificate (CN) to their registered identity to filter the results. +This test case validates that an **AMF Provider** can list rules and that the system correctly maps the Provider's certificate (**CN**) to their registered identity to filter the results. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. -* A Provider has been registered and onboarded at CCF. -* The Provider possesses a valid certificate (in this case AMF certificate). +* The **CAPIF** helper service is deployed and reachable. +* A **Provider** has been registered and onboarded at **CCF**. +* The **Provider** possesses a valid certificate (in this case **AMF** certificate). **Execution Steps**: 1. Authenticate using the **AMF Provider Certificate**. 2. Send a **GET** request to `{apiRoot}/helper/visibility-control/rules`. **Expected Result**: -* **Status**: 200 OK. +* **Status**: **200 OK**. * **Validation**: The response body must only contain rules where the requester is the owner (`userName`). --- @@ -106,23 +106,23 @@ This test case validates that an AMF Provider can list rules and that the system **Test ID**: `visibility_control-5` **Description**: -This test validates the roles and permissions of Superadmin and Providers to create, delete and obtain rules. +This test validates the roles and permissions of **Superadmin** and **Providers** to create, delete, and obtain rules. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. -* A Provider has been registered and onboarded at CCF. -* The Provider possesses a valid certificate (in this case AMF certificate). -* Superadmin has administrative access. +* The **CAPIF** helper service is deployed and reachable. +* A **Provider** has been registered and onboarded at **CCF**. +* The **Provider** possesses a valid certificate (in this case **AMF** certificate). +* **Superadmin** has administrative access. **Execution Steps**: -1. AMF Provider creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. -2. Superadmin sends a **GET** request to `{apiRoot}/helper/visibility-control/rules`. -3. Superadmin sends a **DELETE** request for that `ruleId`. +1. **AMF Provider** creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. **Superadmin** sends a **GET** request to `{apiRoot}/helper/visibility-control/rules`. +3. **Superadmin** sends a **DELETE** request for that `ruleId`. **Expected Result**: -* Provider rule Creation: **201 Created**. -* Superadmin Get: **200 OK**. -* Superadmin Deletion: **204 No Content**. +* **Provider rule Creation**: **201 Created**. +* **Superadmin Get**: **200 OK**. +* **Superadmin Deletion**: **204 No Content**. * **Validation**: The rule is successfully removed from the database. --- @@ -132,19 +132,19 @@ This test validates the roles and permissions of Superadmin and Providers to cre **Test ID**: `visibility_control-6` **Description**: -This test validates tha the Providers can create, delete and obtain rules, ensuring that the identity-based authorization logic correctly identifies the owner of a resource and allows them to delete it without requiring Superadmin intervention. +This test validates that the **Providers** can create, delete, and obtain rules, ensuring that the identity-based authorization logic correctly identifies the owner of a resource and allows them to delete it without requiring **Superadmin** intervention. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. -* A Provider has been registered and onboarded at CCF. -* The Provider possesses a valid certificate (in this case AMF certificate). +* The **CAPIF** helper service is deployed and reachable. +* A **Provider** has been registered and onboarded at **CCF**. +* The **Provider** possesses a valid certificate (in this case **AMF** certificate). **Execution Steps**: -1. AMF Provider creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. -2. AMF Provider **DELETE** the same rule using the same provider identity and the `ruleId`. +1. **AMF Provider** creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. **AMF Provider** sends a **DELETE** request for the same rule using the same provider identity and the `ruleId`. **Expected Result**: -* Status: **204 No Content**. +* **Status**: **204 No Content**. * **Validation**: Subsequent list requests by the provider return an empty set. --- @@ -154,23 +154,23 @@ This test validates tha the Providers can create, delete and obtain rules, ensur **Test ID**: `visibility_control-7` **Description**: -This test validates the `PATCH` implementation. It ensures that Providers can perform partial updates to their rules and that the system correctly updates metadata like `updatedAt`. +This test validates the **PATCH** implementation. It ensures that **Providers** can perform partial updates to their rules and that the system correctly updates metadata like `updatedAt`. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. -* A Provider has been registered and onboarded at CCF. -* The Provider possesses a valid certificate (in this case AMF certificate). +* The **CAPIF** helper service is deployed and reachable. +* A **Provider** has been registered and onboarded at **CCF**. +* The **Provider** possesses a valid certificate (in this case **AMF** certificate). **Execution Steps**: -1. AMF Provider creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +1. **AMF Provider** creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. 2. Send a **PATCH** request to `{apiRoot}/helper/visibility-control/rules/{ruleId}`. -3. Payload: Change `default_access` from "ALLOW" to "DENY". +3. **Payload**: Change `default_access` from **"ALLOW"** to **"DENY"**. 4. Verify the response contains the updated field. -5. AMF Provider **DELETE** the same rule using the same provider identity and the `ruleId`. +5. **AMF Provider** sends a **DELETE** request for the same rule using the same provider identity and the `ruleId`. **Expected Result**: -* **Status**: 200 OK. -* **Body**: Returns the updated `Rule` object showing the new `default_access` value and a refreshed `updatedAt` timestamp, and finally the rule is succesfully removed. +* **Status**: **200 OK**. +* **Body**: Returns the updated `Rule` object showing the new `default_access` value and a refreshed `updatedAt` timestamp, and finally the rule is successfully removed. --- @@ -182,18 +182,16 @@ This test validates the `PATCH` implementation. It ensures that Providers can pe This test verifies the direct resource addressing logic and the error reporting. **Pre-Conditions**: -* The CAPIF helper service is deployed and reachable. +* The **CAPIF** helper service is deployed and reachable. * Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. **Execution Steps**: -1. Superadmin creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. -2. **GET** the specific resource via `{apiRoot}/helper/visibility-control/rules/{ruleId}`. +1. **Superadmin** creates a rule: **POST** request to `{apiRoot}/helper/visibility-control/rules`. +2. Send a **GET** request for the specific resource via `{apiRoot}/helper/visibility-control/rules/{ruleId}`. 3. **DELETE** the resource. 4. Perform the same **GET** request as in step 2. **Expected Result**: -* Step 2: **200 OK** (Returns the specific rule object). -* Step 4: **404 Not Found** (Ensures the resource no longer exists in the registry). - ---- +* **Step 2**: **200 OK** (Returns the specific rule object). +* **Step 4**: **404 Not Found** (Ensures the resource no longer exists in the registry). -- GitLab