successCriteria involving json arrays?

[shah-jh]

(How) can I define a successCriteria for say: https://api.github.com/repos/octocat/boysenberry-repo-1/branches to check if there is a master branch in the response?

ie the equivalent of the following:

curl -s https://api.github.com/repos/octocat/boysenberry-repo-1/branches \
| jq -e 'any(.[]; .name == "master")'

[DmitryAnansky]

@shah-jh
Have you tried:

successCriteria:
  - condition: $statusCode == 200
  - context: $response.body
    condition: '$[?(@.name=="master")]'
    type: jsonpath

[shah-jh]

@shah-jh Have you tried:

successCriteria:

• condition: $statusCode == 200
• context: $response.body
  condition: '$[?(@.name=="master")]'
  type: jsonpath

I'd get:

✗ success criteria check - $[?(@.name=="master")]

for reference, this is what i'm using:

arazzo: "1.0.1"
info:
  title: GitHub Dynamic Branches Validation Journey
  version: "1.0.0"

sourceDescriptions:
  - name: githubApi
    url: https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json
    type: openapi

workflows:
  - workflowId: fetch-repos-and-branches
    steps:
      - stepId: getBranches
        operationId: repos/list-branches
        parameters:
          - name: owner
            in: path
            value: "octocat"
          - name: repo
            in: path
            value: "boysenberry-repo-1"
        outputs:
          branchNames: $response.body[*].name
        successCriteria:
          - condition: $statusCode == 200
          - context: $response.body
            condition: '$[?(@.name=="master")]'
            type: jsonpath

and i'm running it with:

redocly respect github_minimal_journey.arazzo.yaml

worth noting that redocly --version gives me 2.32.2.

[DmitryAnansky]

Hi @shah-jh ,
In your case, data is wrapped into array, so the criteria would be:

    - context: $response.body
      condition: '$[*][?(@.name=="master")]'
      type: jsonpath

You can learn more about jsonPath standard here.

I’m also curious about your use case - are you using respect for testing purposes or as part of a workflow?
If it is for testing - you could probably use simpler condition type, like jsonPointer, but this will only allow you to select the exact position (e.g. $response.body#/2/name == "master").

[shah-jh]

Thank you! that works.

I’m also curious about your use case -

Exploring it for API automation: smoke testing, reproducing customer journeys etc.

While I have your attention here, is it possible to:

• skip success criteria that are not explicitly listed? ie the likes of:

    ✓ status code check - $statusCode in [200, 404]
    ✓ content-type check
    ✓ schema check

• add custom description for the above test and not have the default:

✓ success criteria check - $[*][?(@.name=="master")]

• also, can I add a custom header or query param to a request that's not part of the open-api specs? 🤔

[DmitryAnansky]

Thank you! that works.

I’m also curious about your use case -

Exploring it for API automation: smoke testing, reproducing customer journeys etc.

While I have your attention here, is it possible to:

• skip success criteria that are not explicitly listed? ie the likes of:

✓ status code check - $statusCode in [200, 404]
    ✓ content-type check
    ✓ schema check

• add custom description for the above test and not have the default:

✓ success criteria check - $[*][?(@.name=="master")]

• also, can I add a custom header or query param to a request that's not part of the open-api specs? 🤔

• skip success criteria that are not explicitly listed? ie the likes of:
  Please refer to our Severity Levels documentation, which should be the most relevant for your question:https://redocly.com/docs/respect/guides/severity#disable-openapi-description-checks

• add custom description for the above test and not have the default:
  Names of checks are predefined and can't be changed.

• also, can I add a custom header or query param to a request that's not part of the open-api specs?
  Could you please check our x-operation extension. It should be good option in combination with the existing parameters syntax in Arazzo.

@shah-jh
Please let me know if you have any other questions.

[DmitryAnansky]

@shah-jh
Closing this issue for now.
If you have any further questions or run into any related issues, please feel free to open a new issue.
Thank you!