Les API logicielles ont été l’une des technologies les plus en vogue. Alors que la plupart des tests fonctionnels nécessitent une interaction avec l’interface utilisateur, les tests d’API impliquent de contourner l’interface utilisateur et de communiquer directement avec un serveur d’applications en appelant son API. Les applications Web et les applications mobiles réussies sont toutes le résultat de la meilleure API en backend.
Dans la méthodologie agile, la plupart du temps de l’AQ est consacré à l’automatisation par rapport à l’interface graphique à l’aide de Selenium ou de tout autre framework. Mais dans cet article, nous chercherions le moyen intelligent d’automatiser nos API afin que l’automatisation de l’interface utilisateur puisse être légèrement réduite et que les tests d’automatisation puissent être effectués de manière plus fiable.
À l’avenir, examinons un moyen très simple de créer une API et de configurer un serveur JSON. Ci-dessous se trouve l’exemple JSON nommé entreprises.json que nous utiliserons dans cet article.
{
"E-Commerce": [
{
"id": 1,
"name": "Amazon",
"ceo": "Jeff Bezos",
"isGlobal": true
},
{
"id": 2,
"name": "Flipkart",
"ceo": "Kalyan Krishnamurthy",
"isGlobal": false
}
],
"Banking": [
{
"id": 1,
"name": "JP Morgan",
"ceo": "Jamie Dimon",
"isGlobal": true
},
{
"id": 2,
"name": "Wells Fargo",
"ceo": "Charles W. Scharf",
"isGlobal": true
}
],
"Automobile": [
{
"id": 1,
"name": "BMW",
"ceo": "Harald Krueger",
"isGlobal": true
}
]
}
Dans ce fichier JSON, nous avons collecté les données dans divers secteurs tels que le commerce électronique, la banque et l’automobile.
Puisque nous avons maintenant un fichier JSON, nous sommes prêts à configurer un serveur JSON.
Le serveur JSON est un projet simple qui permet de configurer très rapidement une API REST avec des opérations CRUD.
Le serveur JSON est disponible sous forme de package NPM ; c’est donc une condition préalable à l’installation de NPM. Vous trouverez ci-dessous deux commandes pour configurer et démarrer un serveur JSON :
- $ npm install -g json-server
- $ json-server –watch companies.json
Nous avons utilisé quelques paramètres dans la deuxième commande ci-dessus dans le seul but de démarrer un serveur JSON. Paramètre entreprises.json, censé être un nom de fichier contenant notre structure JSON. De plus, nous avons utilisé un paramètre — watch pour démarrer le serveur en mode watch, ce qui signifie que le serveur surveille les modifications du fichier et manifeste l’API en conséquence.
Une fois votre serveur démarré, le résultat serait le suivant :
Nous pouvons maintenant ouvrir l’URL : http://localhost:3000/ sur laquelle le serveur JSON a été démarré par défaut pour obtenir la vue suivante :
Pour voir les données de chaque secteur, vous pouvez soit cliquer sur les ressources visibles sur la capture d’écran de la page ci-dessus, soit rediriger vers l’URL ci-dessous :
- http://localhost:3000/E-Commerce
- http://localhost:3000/Banque
- http://localhost:3000/Automobile
Si vous connaissez Postman, je vous suggère d’atteindre les points de terminaison API ci-dessous avec Postman avant de passer à l’automatisation de l’API :
GET /Banking
GET /Banking/{id}
POST /Banking
PUT /Banking/{id}
PATCH /Banking/{id}
DELETE /Banking/{id}Les modifications seront automatiquement enregistrées dans entreprises.json selon le JSON que vous donnez dans le corps de la requête en cas de requêtes POST, PUT, PATCH ou DELETE.
Noter: Id est un entier qui est un identifiant par défaut unique pour l’objet JSON d’entrée.
Automatisation des API
Pour l’automatisation des API, nous créerions un projet Maven avec le framework TestNG. Dans cet article, nous utiliserons une bibliothèque jayway-rassured pour l’automatisation. Vous trouverez ci-dessous quelques dépendances qui doivent être incluses dans le pom.xml déposer.
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.14.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.9.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.jayway.jsonpath</groupId>
<artifactId>json-path</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>json-schema-validator</artifactId>
<version>2.9.0</version>
</dependency>
<dependency>
<groupId>org.testinfected.hamcrest-matchers</groupId>
<artifactId>core-matchers</artifactId>
<version>1.5</version>
</dependency>
Obtenir la demande
La requête GET est l’une des requêtes HTTP les plus déclenchées pour récupérer des données d’un serveur pour la ressource spécifiée. Cette requête ne modifie pas l’état des ressources et donne en toute sécurité des données au format JSON.
@Test(description = "Get API method", enabled = true)
public void getAPI()
{
Response response = given()
.param("isGlobal",true)
.param("name", "Wells Fargo")
.when()
.get("http://localhost:3000/Banking");
Assert.assertEquals(response.getStatusCode(), 200,"GET API failed to respond");
System.out.println(response.asString());
}
Sortir:
Procédure pas à pas du code
En utilisant une bibliothèque jayway-restassuré, nous avons utilisé différentes méthodes et interfaces dans le code ci-dessus. Comme, Response est une interface et est utilisé pour enregistrer la réponse des requêtes GET. En tant que méthode, nous avons utilisé given () pour commencer à construire la partie requête, param () pour ajouter des paramètres de requête quand () pour décrire la situation de la requête et get () pour effectuer une requête GET sur un chemin.
De plus, nous avons ajouté des assertions pour vérifier le statut de l’API à l’aide de la méthode getStatusCode(), qui renvoie le statut de la réponse de l’API.
Demande POST
La publication est une méthode HTTP utilisée pour envoyer de nouvelles données au serveur API pour créer ou mettre à jour une ressource. Les données à envoyer sont stockées dans le corps de la requête HTTP. Cela signifie que les données envoyées à la méthode POST ne seront pas visibles dans l’URL car les paramètres ne sont pas envoyés avec l’URI.
@Test(description = "POST API method", enabled = true)
public void postAPI(){
Response response = given().
body(" { "id": 2, "name": "Tesla", "ceo": "Elon Musk", "isGlobal": true }").
when().
contentType(ContentType.JSON).
post("http://localhost:3000/Automobile");
Assert.assertEquals(response.getStatusCode(), 201,"POST API failed to respond");
System.out.println(response.asString());
}
Sortir:
De nouvelles données doivent être ajoutées dans companies.json déposer.
Procédure pas à pas du code
Dans cet exemple de demande de publication, nous envoyons de nouvelles données à notre ressource existante : Automobile. La méthode body() accepte les données de type String telles que JSON ou XML qui doivent être envoyées en tant que corps de requête. La méthode ContentType indique le type de corps dans la requête POST. La méthode post() a été utilisée pour effectuer une requête POST sur un chemin.
Dans la méthode body(), nous avons directement passé du JSON sous forme de String. Cependant, si votre structure JSON est trop longue, pour éviter un processus fastidieux, il est bon de s’entraîner à avoir une nouvelle structure JSON dans un fichier de type JSON différent et de passer le même nom de fichier dans une méthode body() pour obtenir votre JSON lu à partir de le fichier de type JSON lui-même.
METTRE la demande
Semblable aux requêtes POST, la requête PUT est également utilisée pour envoyer des données au serveur API pour créer ou mettre à jour une ressource. La différence entre les requêtes POST et PUT est que les requêtes PUT sont idempotentes et que les requêtes POST sont non idempotentes. Cela signifie que le fait d’appeler plusieurs fois les mêmes requêtes PUT écrasera simplement le même état de ressource encore et encore et ne produirait aucun résultat différent.
PUT implique de mettre une ressource et de remplacer complètement tout ce qui est disponible à une URL de point de terminaison donnée par des données différentes.
@Test(description = "PUT API method", enabled = true)
public void putAPI(){
Response response = given().
body("{"id":2,"name":"Ebay","ceo":"Jamie Iannone"}").
when().
contentType(ContentType.JSON).
put("http://localhost:3000/E-Commerce/2");
Assert.assertEquals(response.getStatusCode(), 200,"PUT API failed to respond");
System.out.println(response.asString());
}
Sortir:
De nouvelles données doivent être ajoutées dans companies.json fichier dans le deuxième objet E-Commerce.
Procédure pas à pas du code
Les méthodes sont plus ou moins les mêmes que celles expliquées dans la requête POST. Le seul changement de méthode est put() au lieu de post(). La méthode put() a été utilisée pour effectuer une requête PUT sur un chemin.
Vous remarquerez que la demande POST renvoie le code d’état 201 et la demande PUT renvoie le code d’état 200. Selon les protocoles W3 :
- 200 : lorsqu’un objet est créé et renvoyé
- 201 : lorsqu’un objet est créé mais que seule sa référence est renvoyée (comme un identifiant ou un lien)
Demande de PATCH
Une demande PATCH est utilisée pour apporter des modifications à la partie spécifique de la ressource. Cette demande est généralement déclenchée pour effectuer des mises à jour mineures, et il n’est pas nécessaire qu’elle soit idempotente. Alors que la méthode PATCH est principalement utilisée pour effectuer de petites mises à jour, la méthode PUT est utilisée pour créer une nouvelle ressource ou remplacer la ressource existante par une nouvelle ressource.
@Test(description = "PATCH API method", enabled = true)
public void patchAPI(){
Response response = given().
body("{"name": "Fabric"}").
when().
contentType(ContentType.JSON).
patch("http://localhost:3000/E-Commerce/1");
Assert.assertEquals(response.getStatusCode(), 200,"PATCH API failed to respond");
System.out.println(response.asString());
}
Sortir:
Les données mises à jour doivent être ajoutées dans companies.json dans le premier objet E-Commerce.
Procédure pas à pas du code
Le code ci-dessus est principalement similaire au code écrit pour les requêtes POST et PUT. La seule différence est que nous avons utilisé la méthode patch(), qui est utilisée pour effectuer des demandes de patch sur un chemin spécifié.
Rappelez-vous toujours qu’en sortie, contrairement à une requête PUT, une requête PATCH ne met à jour que l’emplacement ciblé de la ressource.
Supprimer la demande
Comme son nom l’indique, une demande DELETE est effectuée pour supprimer l’enregistrement existant d’une ressource particulière. Cette requête est l’une des requêtes les plus testées car elles suppriment les données directement de la base de données et peuvent modifier l’état du serveur. Il nécessite un paramètre supplémentaire dans une URL de point de terminaison qui indique la ressource à supprimer.
@Test(description = "Delete API method", enabled = true)
public void deleteAPI(){
Response response = given().
when().
delete("http://localhost:3000/Banking/1");
Assert.assertEquals(response.getStatusCode(), 200,"DELETE API failed to respond");
System.out.println(response.asString());
}
Sortir:
L’enregistrement doit être supprimé de companies.json pour l’objet bancaire un.
Procédure pas à pas du code
Les méthodes et interfaces que nous avons utilisées dans le code de requête DELETE sont probablement les mêmes que celles que nous avons décrites précédemment. La méthode delete() a été utilisée pour effectuer des demandes de suppression sur un chemin.
Temps de réponse
Le temps de réponse est le temps mis par un système pour réagir à une requête envoyée. Lorsque nous automatisons les API, nous vérifions non seulement le code d’état HTTP pour chaque requête, mais nous devons également nous assurer que nous obtenons des réponses du serveur dans un délai suffisant. Le temps de réponse du serveur de 200 à 350 ms est considéré comme rapide, de 351 à 700 ms est moyen et tout le reste peut être qualifié de lent. Vous trouverez ci-dessous l’exemple de code pour extraire le temps de réponse du serveur. Le code ci-dessous a été écrit pour les requêtes GET uniquement. Cependant, cela peut être utilisé avec toutes les requêtes HTTP, c’est-à-dire POST, PUT, PATCH et DELETE, en utilisant les exemples ci-dessus.
@Test(description = "API Response Time", enabled = true)
public void responseTime(){
Response response = given().
when().
get("http://localhost:3000/E-Commerce");
Long...