Utilisation des étapes codées en cours Telerik Test Studio pour les API

Découvrez comment vous pouvez facilement vérifier la fiabilité et l'intégrité de vos API à l'aide d'étapes codées dans Telerik Test Studio.

Grâce à ses fonctionnalités conviviales, son interface utilisateur intuitive et capacités codées ] Progress Test Studio pour les API est un outil très puissant pour les tests API et peut être un ajout intéressant aux tests en ligne Test Studio .

Les étapes codées améliorent considérablement la capacité de l'application à gérer des scénarios de test complexes. Dans ce blog, je vais vous expliquer comment les utiliser en détail.

Présentation

Assurez-vous de jeter un coup d'œil à la section Fonctions du code de notre documentation . Il fournit des informations détaillées sur les étapes codées et leurs fonctionnalités connexes. Dans ce post, nous allons discuter de la construction d'un exemple simple de bout en bout pour vous aider à démarrer avec des étapes codées et vous donner une perspective plus large de leurs capacités.

Vous pouvez également jeter un coup d'œil au projet qui peut être créé dans Progress Test Studio pour les API. Une partie de ses cas de test montre des exemples d'étapes codées (comme la génération d'un nom d'utilisateur aléatoire, la construction d'un simple test piloté par les données et la réutilisation des classes de code auxiliaires)

Test Studio for APIs supporte deux langages de codage: C # et Visual Basic. Pour les besoins de cet article, nous utiliserons C #. Mis à part les différences de syntaxe, il n'y a pas de différences dans la façon dont les caractéristiques codées sont utilisées dans l'application. C'est pourquoi vous pouvez facilement porter les exemples, fournis ici, vers Visual Basic si vous préférez.

Pourquoi les étapes codées?

Test Studio for APIs est construit à partir de zéro avec l'intention de fournir un accès facile. interface d'utilisation pour construire des cas de test rapides et robustes. Vous pouvez utiliser Définir des étapes de variable avec des expressions de chemin d'accès source et diverses conversions de valeur pour extraire des données de demandes HTTP. Les étapes de vérification fournissent une interface utilisateur puissante pour la construction de vérifications complexes. Les conditions Goto et Wait étapes fournissent les moyens de construire un flux de contrôle personnalisé de vos tests.

Toutes les fonctionnalités ci-dessus vous permettront de construire projets de test complexes sans écrire de code. Pourtant, aucune interface utilisateur pourrait couvrir les possibilités infinies de cas d'utilisation que vous pourriez avoir besoin de mettre en œuvre dans vos projets. Lorsqu'il s'agit de construire une logique de test spécifique, où l'interface utilisateur pourrait ne pas suffire, les étapes codées remplissent tout le reste.

Mise en route

Deux des questions que nous avons reçues jusqu'à présent sont: "Comment puis-je générer un nom d'utilisateur aléatoire?" et "Comment puis-je obtenir le nombre total d'éléments retournés sous forme de tableau JSON?" Voici quelques exemples de cas utiles notre exemple dans cet article. Pour les montrer en action, nous pouvons construire un cas de test qui obtient tous les utilisateurs, stocke leur nombre total pour le moment, crée un nouvel utilisateur avec un nom d'utilisateur aléatoire, et finalement récupère tous les utilisateurs et vérifie que leur nombre a augmenté de un.

Tout d'abord, créons un projet de test avec lequel travailler. Cliquez sur Fichier> Nouveau projet et créez un nouveau projet API. Nommez-le CodedStepsDemo . Cela créera un cas de test par défaut avec une requête HTTP. Ce test est créé chaque fois que vous créez un nouveau projet pour vous aider à démarrer. Habituellement, nous allons le supprimer et créer nos propres tests, mais dans ce cas, l'étape de requête HTTP dans le test par défaut correspond parfaitement à nos besoins.

Renommez simplement le scénario de test en" Créer un nouvel utilisateur "et l'étape HTTP en" Obtenez tous les utilisateurs. "

Dans cet exemple, nous allons effectuer nos requêtes HTTP sur une application de démonstration intégrée à Test Studio pour les API. C'est une application de service Web simple qui stocke les utilisateurs et permet d'ajouter, de modifier et de supprimer des utilisateurs. Pour le démarrer, il suffit de cliquer sur le bouton Lancer l'application de démonstration dans la barre d'outils.

Cela va démarrer un simple service web, écoute sur http: // localhost: 5000 .

Cette première étape de requête HTTP fait exactement ce dont nous avons besoin pour commencer: elle récupère tous les utilisateurs existants de l'application de démonstration. retourne une collection JSON avec tous les utilisateurs actuellement enregistrés dans l'application.

Nous pourrions utiliser un Définissez l'étape de variable avec une expression JSONPath pour extraire toute partie de la réponse dont nous pourrions avoir besoin pour les étapes suivantes. Vous ne pouvez pas obtenir le nombre total d'éléments dans la collection JSON juste avec une expression JSONPath cependant ( Test Studio pour les API utilise JSON.Net pour analyser les expressions JSONPath, et au moment de l'écriture de cet article, JSON.Net ne supporte pas cela. ) C'est pourquoi nous aurons besoin d'une étape codée distincte pour que le tableau compte.

Création de la première étape codée

Pour créer votre première étape codée, right- cliquez sur le scénario de test dans l'Explorateur de projet et sélectionnez Ajouter une étape> Étape codée

le premier élément codé que vous créez dans ce projet, vous serez invité à sélectionner le langage de codage pour le projet.La définition du langage de codage est une opération unique et ne peut pas être modifiée ultérieurement. C # et cliquez sur OK

Encore une chose qui va arriver w En créant cette étape codée, un fichier code-behind sera créé et associé au cas de test (car il s'agit de la première étape codée ajoutée à ce cas de test). Laissons l'étape codée en arrière pendant un moment et vérifions ce qui se passe dans le code-behind du test. Cliquez sur le bouton "Open Code-Behind" – soit à côté du cas de test dans l'Explorateur de projet, soit à l'intérieur de l'étape codée.

Le fichier code-behind du test est créé avec une classe publique, nommée en fonction du nom du cas de test lui-même (mais excluant les caractères invalides).

Pour vous aider, La méthode par défaut "TestMethod" est générée avec quelques indications.

Renommez la méthode de test par défaut avec un nom plus convivial, par exemple " StoreAllUsersCount " et supprimez les commentaires de l'indice pour faire de la place à votre code

Accéder aux variables de contexte du code

Ensuite, nous devons accéder au corps de réponse de la dernière requête HTTP de notre code. La classe de base que toutes les classes code-behind implémentent est ApiTestBase . Il expose une propriété Context de type IContext et fournit les méthodes permettant d'accéder aux variables dans le contexte actuel: SetValue () et GetValue () (En savoir plus sur la propriété Context dans notre documentation ).

 public void StoreAllUsersCount ()
{
  var body = this.Context.GetValue ("Corps");
} 

Utilisation d'une bibliothèque externe

Nous devons analyser le contenu JSON du corps de la réponse. Nous pouvons utiliser Json.NET pour cela, mais nous devons ajouter une référence d'assembly à son fichier .dll dans notre projet. Vous pouvez télécharger Json.NET en tant que fichier .zip à partir de ici et extraire le fichier .zip sur votre machine. À partir du répertoire extrait, vous pouvez copier le fichier ". Lib net45 Newtonsoft.Json.dll " et le déplacer vers le dossier souhaité que vous souhaitez faire référence à l'assembly.

pouvez ajouter le fichier d'assemblage dans le dossier de votre projet de test ou dans n'importe quel répertoire de votre machine. Vous pouvez également l'installer dans votre Global Assembly Cache (GAC) . Où que vous décidiez de stocker le fichier d'assemblage, les étapes pour ajouter une référence sont les mêmes:

1. Ouvrez votre projet de test. Faites un clic droit sur l'élément racine de votre projet et sélectionnez Propriétés ou cliquez sur le bouton Modifier les propriétés du projet dans la barre d'outils

2. Dans la section References cliquez sur le bouton Add Reference (s) et naviguez jusqu'au dossier où l'assemblage Sélectionnez le fichier d'assemblage et cliquez sur Ouvrir Pour plus de simplicité, je placerai le fichier Newtonsoft.Json.dll à la racine de mon projet de test.

3. Le nouvel assembly apparaîtra dans la liste des assemblys référencés. Cliquez sur Enregistrer pour enregistrer les modifications et fermer la boîte de dialogue Propriétés

Notez qu'il peut ne pas être judicieux de conserver les assemblys externes dans votre répertoire de projet et de les ajouter sous le contrôle de la source dans le reste des fichiers du projet, car cela augmentera la taille globale de votre référentiel source-control. comptez sur les assemblages pour être disponibles dans le Global Assembly Cache ou dans n'importe quel dossier sur la machine, vous devrez vous assurer qu'ils sont disponibles sur chaque machine où vous pourriez distribuer et exécuter vos tests. résoudre ce problème, en restaurant les assemblages référencés, en utilisant NuGet mais je laisserai cela comme sujet pour un futur article de blog

Maintenant que nous avons ajouté la référence d'assemblage, nous pouvons utiliser Json.NET dans notre fichier code-behind, pour analyser le corps de la réponse

Réutilisation des éléments de code autonomes

Comme nous aurons besoin du même code plus tard pour une autre étape codée, nous devrions l'ajouter comme méthode réutilisable. Nous pourrions le faire dans une méthode privée dans notre classe code-behind, mais pour la démonstration, je vais le créer dans un fichier d'éléments de code séparé . Les éléments de code sont des fichiers de code distincts qui ne sont pas liés à un scénario de test particulier. Cela les rend utiles pour séparer la logique de code réutilisable (comme les méthodes d'assistance) accessible à partir de chaque classe code-behind.

Je vais créer un dossier séparé dans le projet, appelé Utilities où stockerait tous les éléments de code auxiliaire réutilisables qui ne sont pas spécifiques au contexte pour un cas de test ou une suite de tests (dossier) particuliers. Pour créer un nouvel élément de code cliquez avec le bouton droit sur un dossier (ou la racine du projet) et sélectionnez Ajouter un élément de code .

Donner un nom au nouvel élément de code (par exemple BodyParser ).

Dans le nouvel élément de code, ajoutez une directive utilisant Newtonsoft.Json.Linq; rendez la classe générée statique ] et ajoutez une méthode publique statique statique appelée " GetCollectionCount ".

 using System;
en utilisant Telerik.ApiTesting.Framework;
en utilisant Telerik.ApiTesting.Framework.Abstractions;
en utilisant Newtonsoft.Json.Linq;

espace de noms CodedStepsDemo.Utilities
{
  Classe publique publique BodyParser
  {
    public static int GetCollectionCount (corps de chaîne)
    {
      var parsedBody = JArray.Parse (corps);
      return parsedBody.Count;
    }
  }
} 

Une fois la classe BodyParser créée, nous pouvons la réutiliser à partir du code du test Assurez-vous d'ajouter une directive correspondant à l'espace de nom de l'espace de nom de l'élément de code ( CodedStepsDemo.Utilities dans ce cas).

 utilisant le système;
en utilisant Telerik.ApiTesting.Framework;
en utilisant Telerik.ApiTesting.Framework.Abstractions;
en utilisant CodedStepsDemo.Utilities;

espace de noms CodedStepsDemo
{
  classe publique CreateNewUser: ApiTestBase
  {
    public void StoreAllUsersCount ()
    {
      var body = this.Context.GetValue ("Corps");
      var usersCount = BodyParser.GetCollectionCount (body.ToString ());

      this.Context.SetValue ("initialUsersCount", usersCount, 0);
    }
  }
} 

Nous allons utiliser la méthode Context.SetValue pour stocker le résultat dans une variable d'exécution nommée initialUsersCount . Notez le dernier argument de l'appel de méthode SetValue : this.Context.SetValue ("initialUsersCount", usersCount, 0); . L'argument " 0 " définit le contexte de la variable stockée dans le scénario de test actuel. Si vous utilisez " 1 " à la place, cela sauvegardera la variable dans la portée du projet racine et elle sera accessible par tous les cas de test. Actuellement, nous avons seulement besoin de la variable dans le test en cours, nous utiliserons donc " 0 " pour ne pas polluer la portée racine avec des variables inutiles. (Vous pouvez même omettre complètement le " 0 ", car c'est la valeur par défaut de ce paramètre.)

Maintenant que la méthode code-behind est prête, nous pouvons ouvrir l'étape codée et sélectionner la nouvelle méthode

Erreurs de code de manipulation

Par souci de brièveté dans les exemples de cette Dans l'implémentation actuelle, si le corps de réponse reçu n'est pas la chaîne de tableau JSON attendue (par exemple, si le serveur de test renvoie un résultat inattendu), son analyse échouera et JSON.Net lancera une exception JsonReaderException Comme l'exception n'est pas gérée dans notre méthode GetCollectionCount elle sera propagée vers le haut et le scénario de test échouera avec une erreur comme celle-ci dans Volet de sortie :

 12: 00: 46.497 [ERROR] [FAILED]   | 'Coded Step' StoreAllUsersCount '' [44 ms] [3Xx0gPbpRLmGho8yvE7ITX]  'Erro Je lis JArray de JsonReader. L'élément JsonReader actuel n'est pas un tableau: StartObject. Chemin '', ligne 1, position 1. '

En termes d'exécution de test, exceptions non gérées dans le code de test est géré par le moteur d'exécution de Progress Test Studio pour les API, ce qui signifie que si une étape codée déclenche une exception, elle sera correctement marquée comme ayant échoué et l'exécution du test se poursuivra avec le prochain cas de test. pour voir le message d'exception dans le résultat du test, cela vous suffira dans la plupart des cas pour détecter le problème de vos tests (voir cet article de documentation pour des conseils sur la façon de déboguer votre code. Cependant, les exceptions non gérées dans votre code peuvent ne pas toujours être assez descriptives pour que vous puissiez suivre la cause première d'un test défaillant, c'est pourquoi vous pouvez approcher le code de vos éléments codés de la même manière que vous le feriez pour n'importe quelle application. code que vous écrivez et ajoutez une gestion correcte des erreurs. 59008] Méthode GetCollectionCount ci-dessus, vous pouvez envelopper votre code dans une clause try-catch et lancer votre propre exception si nécessaire.

 using System;
en utilisant Telerik.ApiTesting.Framework;
en utilisant Telerik.ApiTesting.Framework.Abstractions;
en utilisant Newtonsoft.Json.Linq;

espace de noms CodedStepsDemo.Utilities
{
  Classe publique publique BodyParser
  {
    public static int GetCollectionCount (corps de chaîne)
    {
      essayer
      {
        var parsedBody = JArray.Parse (corps);
        return parsedBody.Count;
      }
      catch (Exception ex)
      {
        throw new Exception ("Impossible de récupérer le nombre de collections de 'Body'. Message:" + ex.Message);
      }
    }
  }
} 

De cette façon, vous obtiendrez le message suivant dans la sortie du test, qui est un peu plus descriptif:

 12: 03: 09.984 [ERROR] [FAILED]   | | 'Coded Step' StoreAllUsersCount '' [39 ms] [3Xx0gPbpRLmGho8yvE7ITX]  'Impossible de récupérer le nombre de collections à partir de' Body '. Message: Erreur lors de la lecture de JArray à partir de JsonReader. L'élément JsonReader actuel n'est pas un tableau: StartObject. Chemin '', ligne 1, position 1. '

Génération d'un nom d'utilisateur aléatoire

L'étape suivante consiste à créer un nouvel utilisateur. Nous pourrions simplement créer le nouvel utilisateur avec un nom d'utilisateur codé en dur, mais si vous exécutez ce test deux fois sans effacer l'état de l'application testée, vous obtiendrez une erreur indiquant que l'utilisateur existe déjà. Dans certains scénarios de test, cela correspond au comportement souhaité et vous vous fiez toujours à démarrer vos tests sur un environnement préconfiguré (par exemple, en réinitialisant votre base de données à chaque fois sur un «ensemble de données en or»). Dans d'autres cas, la réinitialisation de l'état de la base de données peut ne pas être appropriée. C'est à ce moment que vous devrez générer un nom d'utilisateur unique (ou un nom de projet, ou toute valeur dont vous pourriez avoir besoin pour être unique). C'est là que les étapes codées peuvent être utiles dans Progress Test Studio pour les API.

Pour générer un nom d'utilisateur unique, nous allons créer une autre étape codée dans le scénario de test. Nommez-le " Générer nom d'utilisateur aléatoire ". Dans l'étape codée, cliquez sur la liste déroulante Méthode et sélectionnez .

créer automatiquement une nouvelle méthode vide dans le fichier code-behind.Vous pouvez simplement le renommer (par exemple, " GenerateRandomUsername ") et ajouter la logique appropriée dans son corps.

 public void GenerateRandomUsername ()
{
  var randomSuffix = Guid.NewGuid (). ToString (). Sous-chaîne (0, 7);
  var username = "Utilisateur-" + randomSuffix;
  this.Context.SetValue ("nom d'utilisateur", nom d'utilisateur, 0);
} 

Ensuite, revenez à l'étape Generated Random Username et sélectionnez GenerateRandomUsername comme valeur dans sa liste déroulante.

Nous pouvons utiliser la variable nom d'utilisateur dans une nouvelle étape de requête http pour créer le nouvel utilisateur. Créez une nouvelle étape de requête http nommée Créer un nouvel utilisateur avec les propriétés suivantes:

• Méthode: POST
• URL: {{base-url}} / api / users [19659090] En-têtes: Content-Type: application / json
• Corps: {"userName": "{{nom d'utilisateur}}", "email": "{{nom d'utilisateur}}@test.com" }

Vous pouvez également ajouter une vérification du code d'état à cette demande:

Étape Créer un nouvel utilisateur, nous devons ajouter une requête GET supplémentaire pour récupérer la liste mise à jour des utilisateurs.Pour ce faire, nous pouvons simplement copier-coller le premier test Get All Users.

Enfin, nous avons besoin d'une dernière étape codée, pour analyser le corps de la dernière réponse et comparer le nouveau sers compte avec le compte initial.

Dans le fichier code-behind du test, ajoutez une nouvelle méthode nommée AssertUserCountIsIncremented qui récupère le nombre d'utilisateurs basé sur le corps de la dernière réponse, obtient la variable "initialUsersCount" déjà stockée et vérifie qu'un utilisateur a été ajouté.

 public void AssertUserCountIsIncremented ()
{
  var body = this.Context.GetValue ("Corps");
  var updatedUsersCount = BodyParser.GetCollectionCount (body.ToString ());
  
  var initialUsersCount = (int) this.Context.GetValue ("initialUsersCount");
  
  Assert.AreEqual (initialUsersCount + 1, updatedUsersCount, "Le nombre d'utilisateurs n'est pas correctement incrémenté.");
} 

Notez l'instruction Assert à la fin du AssertUserCountIsIncremented Progress Test Studio pour les API fournit un cadre Assert simple qui peut être utilisé pour effectuer des vérifications dans vos fichiers de code Si une instruction Assert échoue, l'étape de test et le scénario de test correspondants échoueront avec le message approprié

Sélectionnez la méthode AssertUserCountIsIncremented dans la dernière étape codée et le scénario de test est terminé et prêt à être exécuté

Résumé

Dans cet article, nous avons créé un cas de test simple qui utilise des étapes codées pour générer des données aléatoires et analyser le contenu de la réponse JSON. Nous vous avons montré comment accéder au contexte de test pour stocker ou récupérer des variables. Nous avons également créé un élément de code réutilisable pouvant être utilisé par plusieurs tests et montré comment les utiliser dans le code code-behind d'un scénario de test. Vous pouvez télécharger le projet avec les exemples du blog à droite ici . J'espère que cela vous aidera à commencer à utiliser les étapes codées dans Progress Test Studio for API .

N'hésitez pas à partager vos commentaires ou demandes de fonctionnalités avec nous sur notre Feedback Portal

Test Studio for APIs est disponible dans le cadre de Test Studio Ultimate. Essayez-le gratuitement dès aujourd'hui.

Essayez Test Studio