Paramétrage dans Rest Assured API Automation à l’aide du mot-clé Exemples.

Introduction:

Ce blog décrit la stratégie pour paramétrer votre code d’automatisation d’API à l’aide du mot-clé Exemples dans les fichiers de fonctionnalités afin d’optimiser votre script/code.

Dans les tests API, l’automatisation de l’ensemble des tests fonctionnels est une pratique très courante dans l’industrie. Il existe de nombreux outils/bibliothèques disponibles sur le marché. En les utilisant, nous pouvons réaliser une automatisation complète de bout en bout. Mais lorsque vous travaillez sur un projet de grande envergure, vous devez exécuter votre script de test avec un grand nombre de données de test. Dans ce scénario, nous devons paramétrer les données de test pour garantir une exécution de bout en bout et gérer les données de test en un seul endroit.

De plus, si nous implémentons le paramétrage dans les données de test, cela finit par optimiser le code et donne une meilleure lisibilité du code.

Ce que vous apprendrez de ce blog :
Un moyen d’optimiser votre code d’automatisation à l’aide de Exemples mot-clé dans le fichier de fonctionnalités.

Tech Stack utilisé dans ce blog :
Ici, dans ce blog, la pile technologique utilisée est JAVA, Rest Assured, BDD et Cucumber. Pour la démo, j’utilise une API ouverte disponible « http://postalpincode.in/api/pincode/ ».

Commençons :
En temps réel, lorsque nous écrivons nos scripts d’automatisation pour vérifier l’API avec plusieurs données de test, une méthode courante consiste à écrire les scénarios avec toutes les données de test possibles.
Considérons l’exemple ci-dessous pour comprendre cela.

API – http://postalpincode.in/api/pincode/110016 Ce point de terminaison prend n’importe quel code postal indien en entrée et renvoie toutes les listes des bureaux de poste de cette zone. Nous écrivons donc ici le script d’automatisation pour trois cas de test différents répertoriés ci-dessous.

Cas 1 : tout code postal valide de l’Inde. Par exemple. 110016
Cas 2 : tout code postal de l’Inde invalide. Par exemple. 111100
Cas 3 : Code postal valide de l’Australie. Par exemple. 4215

Si nous suivons la manière normale d’écrire les cas de test dans le fichier de fonctionnalités, nous devons alors écrire les trois scénarios avec tous les différents ensembles de données de test. Reportez-vous à la capture d’écran ci-dessous pour la même chose.

En examinant les trois cas de test ci-dessus, nous pouvons dire que la couverture du code est terminée, mais nous devons écrire le script de test réel dans (Définition de l’étape) trois fois pour toutes les entrées. Cela augmente la complexité temporelle et la répétition du code et le fichier de fonctionnalités semble également très volumineux. Nous pouvons surmonter cette situation en optimisant notre fichier de fonctionnalités et en implémentant le mot-clé Exemples. Reportez-vous à la capture d’écran ci-dessous pour le fichier de fonctionnalités optimisé.

Dans le fichier de fonctionnalités ci-dessus, les trois cas de test sont couverts dans un seul scénario. De même, nous pouvons ajouter N nombre de cas de test dans un seul scénario et optimiser notre code.

Script de test réel (définition de l’étape) :

Après avoir créé le fichier de fonctionnalités, nous devons écrire le script de test de la même manière afin qu’il puisse mapper tous les cas définis dans le fichier de fonctionnalités. Veuillez trouver le script de test (définition de l’étape) ci-dessous.

public class postOffice_API_TestScript 

{

RequestSpecification request = RestAssured.given();

JSONObject objjson;

Response response ;

String endPoint = "http://postalpincode.in/api/pincode/";

@Given("User calls the API with the Zip Code as {string},{string}")

public void user_calls_the_api_with_the_zip_code_as(String zipcode, String caseType )

{

switch (caseType) 

{

case  "Valid Indian ZipCode" :

String API_URL =  endPoint+zipcode;

response = request.get(API_URL);

break;

    case  "Invalid Indian ZipCode" :

    String api_URL =  endPoint+zipcode;

    response = request.get(api_URL);

    break;

    case  "Australia ZipCode" :

    String Api_URL =  endPoint+zipcode;

    response = request.get(Api_URL);

   break;

}

}

@Then("In the API response the Status is {string},{string}")

public void in_the_api_response_the_status_is(String ResponseStatus, String caseType) 

{    

switch (caseType) 

{

  case  "Valid Indian ZipCode" :

  String API_Status  = response.jsonPath().get("Status");

      assertEquals(API_Status,ResponseStatus );   

       break;

      case  "Invalid Indian ZipCode" :

     String API_status  = response.jsonPath().get("Status");

     assertEquals(API_status,ResponseStatus );  

     break;

   case  "Australia ZipCode" :

     String api_Status  = response.jsonPath().get("Status");

     assertEquals(api_Status,ResponseStatus );   

     break;   

}

}

}

Conclusion:

L’approche du blog illustre que la mise en œuvre de la paramétrisation nous aide à optimiser nos scripts de test. Initialement, sans utiliser les exemples, nous avions l’habitude d’écrire les scénarios et les définitions d’étapes correspondantes pour chaque ensemble de données de test, mais après avoir implémenté les exemples, nous y sommes parvenus dans un seul scénario pour tous les ensembles de données de test.

VOUS TROUVEZ CELA UTILE ? PARTAGEZ-LE