Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand

The following abbreviations are used in the functional test case description below since there may be substantial repetition along with clarification notes associated with some terms

  1. CHECK-REQ-OR-OPTIONAL

    1. Check if the test is required or optional. For instance, health checks for dependencies is likely optional because this will be captured in the tests for request/response

  2. EMULATORS-OR-SERVICES-ARE-UP

    1. Emulator or service should be up and running

    2. Emulator or service configuration file should be available and loaded

    3. Notes: For OOF internal components (e.g. OOF-OSDF connecting to OOF-HAS API), real services may be used when convenient

  3. HTTP-200-TRUE
    1. Component (or all components) should return health status as “true” (HTTP response code of 200, response content containing the string "true")

    2. Notes: (a) Verify whether the external components also have standardized on "true" as the value
  4. SIMPLE-GET-HEALTH-CHECK-API
    1. API: healthcheck
    2. HTTP Request Method: GET
    3. HTTP Endpoint: http://<host>:<port>/healthcheck 
    4. Notes: (a) check whether https can/should be used, and whether mutual TLS is required when using OOM/K8S, and
      (b) verify if the health check is required for dependencies (it will help in quickly debugging but will add extra logic in our testing)
  5. SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES
    1. API: specific to each component

    2. Endpoint: http://<host>:<port>/<specific-API>

    3. Method - POST in most cases; GET in some cases

    4. Notes: (a) check whether https can/should be used, and whether mutual TLS is required when using OOM/K8S

Anchor
OOF Beijing Release Functional Test Cases
OOF Beijing Release Functional Test Cases
OOF-OSDF Beijing Release CSIT Functional Test Cases 

Id

Description

Pre-conditions

Test Steps

Expected Results

A: Health Checks for OOF-OSDF Components and Dependencies (Policy and OOF-HAS API)

A.1

Perform health check for the OOF-OSDF components using Health Check API

  •   OSDF Manager

[OSDF Manager]
EMULATORS-OR-SERVICES-ARE-UP

Server and authentication details should be configured at $OOF_HOME/config/feature-healthcheck.properties

SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE

A.2

CHECK-REQ-OR-OPTIONAL
Perform health check for the following external components and OOF components using Health Check API:

  • Policy (external component)
  • OOF-HAS API (OOF component)

[Policy Emulator]
[
OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP


SIMPLE-GET-HEALTH-CHECK-API

HTTP-200-TRUE


B: Fetch Data from Emulators (valid and invalid data, via GET and POST)

B.1

Post Valid Retrieve data

Retrieve response corresponding to "valid request" from HAS-API emulator

(or HAS-API container)OSDF → HAS (POST with valid and invalid templates

  • OSDF → HAS (POST data)

[OOF-HAS API – container or emulator]EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads and Endpoint

Should receive response for valid request

TODO: Payloads

B.2

Retrieve response corresponding to "valid policy query" from Policy emulator

  • OSDF → Policy (POST query data)


[Policy]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads and Endpoint

Should receive response for valid policy query

TODO: Payloads

B.3

CHECK-REQ-OR-OPTIONAL
OSDF → Policy (bad result)
OSDF → HAS (GET; bad status

/solution

)
OSDF →

Policy (POST to query policy

HAS (GET; solution found)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads and Endpoint

Should receive

expected data:

corresponding responses

TODO: Payloads

C: Run Complete Requests for Different Applications

C.1SO → OSDF → HAS (well formatted request)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads, Endpoint, and Call-Back URL

Should receive a valid Conductor reponse

TODO: Payloads

C.2

CHECK-REQ-OR-OPTIONAL
SO → OSDF → HAS (mal-formatted request or a data error so that the request goes through OSDF but fails at Conductor)

[Policy Emulator]
[OOF-HAS API – container or emulator]
EMULATORS-OR-SERVICES-ARE-UP

SIMPLE-GET-POST-TO-EMULATORS-OR-SERVICES

TODO: Payloads, Endpoint, and Call-Back URL

Should receive a RequestError or an error from Conductor

TODO: Payloads


Test Planning for OOF Homing and Allocation Service (OOF-HAS)

...