Bibliothèque de test de l'API JSON-RPC

Lorsque j'ai rencontré pour la première fois des tests d'écriture pour un microservice, dont l'API a été implémentée selon le protocole JSON-RPC, j'ai réalisé que la construction de contrôles de qualité pour les éléments json est beaucoup plus exigeante que je ne le pensais auparavant.

Voici un exemple simple.

Une réponse a été reçue du service:

{ "result": 12, "id": 46929734, "jsonrpc": "2.0" } 

Ce que vous devez vérifier:

  1. La réponse contient un élément jsonrpc et sa valeur est 2.0
  2. La réponse contient un élément id et sa valeur est égale à un élément similaire passé dans la requête, pour le moment disons qu'il est 46929734

La réponse contient l'élément "résultat" et sa valeur est 12


Comment vérifier cela en utilisant Java + TestNG + Gson:

 Assert.assertTrue(response.has("result")); Assert.assertTrue(response.has("jsonrpc")); Assert.assertTrue(response.has("id")); Assert.assertTrue(response.get("result").isJsonPrimitive()); Assert.assertTrue(response.get("jsonrpc").isJsonPrimitive()); Assert.assertTrue(response.get("id").isJsonPrimitive()); Assert.assertEquals(response.get("result").getAsInt(), 12); Assert.assertEquals(response.get("jsonrpc").getAsString(), "2.0"); Assert.assertEquals(response.get("id").getAsInt(), 46929734); 

En ce moment, la question «Pourquoi y a-t-il tant d'affirmations?» Peut commencer à se former dans l'esprit. Oui, en fait, lors des tests, vous n'êtes intéressé que par le groupe des trois dernières assertions, ils vérifient les valeurs json des éléments dans la réponse et s'ils passent, alors la réponse répond aux attentes. Mais que faire si le test échoue? Considérez plusieurs raisons possibles à la chute d'un tel test:

  1. Réponse ->
     { "result": 12, "id": 46929734, "jsonrpc": "1.0" } 

    Erreur de TestNG -> java.lang.AssertionError: attendu [2.0] mais trouvé [1.0]
    Ils ont attendu "2.0" , "1.0" - tout est clair ici.
  2. Réponse ->
     { "result": 12, "id": 46929734, "jsonrpc": {} } 

    Erreur de TestNG -> java.lang.UnsupportedOperationException: JsonObject

    Ils ont essayé d'analyser un élément en tant que chaîne, qui a été reçue de manière absolument inattendue dans la réponse en tant qu'objet.
  3. Réponse ->

     { "result": 12, "id": 46929734 } 

    Erreur de TestNG -> java.lang.NullPointerException
    Nous avons essayé d'analyser un élément qui n'est pas dans la réponse sous forme de chaîne.

Avec le premier exemple, tout va bien. L'erreur est compréhensible, les valeurs réelles et attendues sont immédiatement visibles. Mais les deuxième et troisième exemples ne peuvent s'en vanter. Une telle baisse prend du temps au testeur pour analyser la cause. Débiter une telle erreur superficielle est difficile. Il faudra du temps pour comprendre quel élément particulier le test a tenté d'analyser, quelle méthode il a essayé d'analyser et à quoi ressemblait réellement cet élément dans la réponse. Vous devrez peut-être même redémarrer le test localement, simplement parce que cela peut être plus rapide que de collecter toutes les informations nécessaires à partir des journaux de l'assembly de test.

Un tel nombre de vérifications, la nécessité de les écrire et de les soutenir dans un état à jour, m'a énervé, j'ai donc créé une bibliothèque séparée dans laquelle j'ai collecté toutes les vérifications nécessaires, à mon avis, pour les éléments json. Le même niveau de couverture et de détails qui nécessitait le json ci-dessus en utilisant la bibliothèque est atteint en trois lignes, au lieu de neuf.

 Gassert.verifyInteger(response, "result", 12); Gassert.verifyString(response, "jsonrpc", "2.0"); Gassert.verifyInteger(response, "id", 46929734); 

La bibliothèque implémente des méthodes de vérification:

  • éléments de tous types primitifs, imbriqués et non, avec vérification de la valeur et sans
  • JsonObject, imbriqué et non, avec contrôle de valeur et sans
  • JsonArray, imbriqué et non, avec et sans vérification de valeur
  • Éléments JsonNull imbriqués et non
  • types d'éléments à l'intérieur d'un tableau
  • le contenu du tableau d'éléments attendu
  • dimensions du tableau
  • dimensions de l'objet

À tous les niveaux de vérification, des erreurs plus détaillées sont implémentées par rapport à celles que TestNG fournit par défaut.

Considérez à nouveau les causes possibles de la chute du test:

  1. Réponse ->
     { "result": 12, "id": 46929734, "jsonrpc": "1.0" } 

    Erreur de Gassert -> java.lang.AssertionError: la vérification de l'élément [jsonrpc] a échoué. attendu [2.0] mais trouvé [1.0]
  2. Réponse ->

     { "result": 12, "id": 46929734, "jsonrpc": {} } 

    Erreur de Gassert -> java.lang.AssertionError: l'élément [jsonrpc] n'est pas un JsonPrimitive. ne s'attendait pas à trouver [vrai] mais a trouvé [faux]
  3. Réponse ->

     { "result": 12, "id": 46929734 } 

    Erreur de Gassert -> java.lang.AssertionError: Json ne contient pas d'élément: [jsonrpc]. ne s'attendait pas à trouver [vrai] mais a trouvé [faux]

De plus, la plupart des méthodes de vérification sont surchargées avec un paramètre de chaîne supplémentaire, qui en cas de chute d'assertion sera ajouté au texte de l'erreur affichée. Cette fonctionnalité peut être utilisée, par exemple, pour afficher le corps complet d'une réponse ou d'une requête + réponse par erreur.

La bibliothèque se trouve dans le référentiel github public et a également été ajoutée au référentiel maven.

Maven
Github
APIDocs

Source: https://habr.com/ru/post/fr480976/


All Articles