Skip to content

Latest commit

 

History

History
44 lines (33 loc) · 2.99 KB

API-Testing-Guidelines.md

File metadata and controls

44 lines (33 loc) · 2.99 KB

API Testing Guidelines

Table of Contents

  1. Introduction
  2. Test Cases contributions for APIs
  3. Location of feature file
  4. Best practices and recommendations
  5. References

Introduction

This document captures guidelines for the API testing in CAMARA project. These guidelines are applicable to every API to be worked out under the CAMARA initiative.

Test Cases contribution for APIs

Based on the decision taken in the Commonalities working group and as documented in API-Readiness-Checklist, at least one Gherkin feature file will be added to the main subproject repo and this will fulfill the minimum criteria of readiness with respect to API test cases and documentation. If subprojects also intend to add test implementations, an aligned single implementation that is agreed among all provider implementors could be added to the main subproject repo. If no alignment is possible, each provider implementer will add the test implementation to their own repos.

Location of feature file

The feature file will reside under

Subproject_Repository/code/Test_definitions/file_name.feature
for e.g. https://github.com/camaraproject/QualityOnDemand/blob/main/code/Test_definitions/QoD_API_Test.feature

Best practices and recommendations

  • Granularity of the feature file must be decided at the project level but it is recommended to:

    • group in one file all scenarios testing one closely related API capability (that can cover one or several endpoints).
    • provide several files when one CAMARA API (yaml) covers several independent functions that can be provided independently

  • Third Person pronoun usage in feature file is advisable as using the third person, conveys information in a more official manner.

  • It is recommended to only have one When/Then in a feature file as per cucumber official documentation's recommendations. However, in case of complex scenarios, several when/then can be allowed.

  • The recommended format for scenario identifier is shown below

    '@'<(mandatory)name of the resource>_<(mandatory)number XX>_<(optional)short detail in lower case and using underscore “_” as the separator>)
  for e.g. (@check_simswap_01_verify_swap_true_default_maxage).

  • Recommendation is to have API literal request value (with example) but in case of exceptions, it is fine to use ready payload as well.

References