Tests pilotés par les données ou paramétrés avec Spock Framework

data driven parameterized testing with spock framework

Explorez les moyens d'écrire des tests pilotés par les données ou paramétrés avec Spock Framework:

Dans ce Série de didacticiels gratuits sur la formation Spock , nous avons tout exploré Tests unitaires dans Spock et testez les montages, les assertions et les rapports dans notre précédent didacticiel.

Dans ce didacticiel, nous allons essayer de comprendre ce que sont les tests paramétrés et comment vous pouvez tirer parti des fonctionnalités intégrées de Spock pour réaliser des tests basés sur les données.

Commençons!!

Regardez le didacticiel vidéo

Ce que vous apprendrez:

• Que sont les tests paramétrés?
• Ecrire des tests paramétrés avec Spock
  • Le où: bloc
  • Utilisation des tables de données
• Cycle de vie du bloc «où»
• Conseils & Astuces
• Conclusion
• lecture recommandée

Que sont les tests paramétrés?

Pour tous ceux qui ont travaillé avec des tests d'automatisation / unitaires, les tests basés sur les données ne sont pas un nouveau terme.

Les tests paramétrés ne sont rien, mais ce sont des types de tests qui partagent la même logique d'exécution et ne diffèrent que par les données d'entrée et les résultats dans certains cas.

Exemple: Supposons que vous ayez une application Calculatrice, afin de tester complètement la fonctionnalité, vous souhaiterez peut-être exécuter vos tests sur différents ensembles d'entrées.

Exemple: Valeurs négatives, nombres fractionnaires, entiers normaux, entiers proches de la plage maximale autorisée, etc. Quelles que soient les valeurs d'entrée que vous avez, vous souhaitez exécuter la même logique d'exécution.

Une autre bonne raison d'écrire des tests paramétrés est qu'il ne teste pas seulement un chemin heureux, mais il teste également le chemin d'erreur ou des scénarios négatifs.

Exemple: Supposons qu'une application retourne si une extension de fichier donnée est valide ou non. Les tests basés sur les données peuvent rapidement permettre au développeur d'exécuter des tests pour les extensions de fichier prises en charge et tout scénario d'erreur ou test d'entrée négatif.

Maintenant, traditionnellement, vous pouvez penser à écrire ou à copier les tests pour plusieurs valeurs d'entrée, mais ce n'est pas la manière correcte ou intelligente de réaliser ce type d'exécution de test. De plus, à mesure que le nombre de tests augmente dans votre application, ces tests deviendront difficiles à maintenir.

Ecrire des tests paramétrés avec Spock

Le où: bloc

Le bloc where dans un test Spock, est le bloc qui contient les données pour le test paramétré. Il peut éventuellement contenir des valeurs d'entrée et de sortie attendues. Un point important à noter à propos de ce bloc est qu'il devrait être le dernier bloc d'un test Spock.

Cela dit, il peut être combiné avec tous les autres blocs comme donné, quand et alors mais devrait être le dernier bloc.

Regardons un exemple pour mieux le comprendre

Nous allons utiliser une application de calcul qui prend 2 paramètres d'entrée et renvoie la somme des entrées fournies. Nous allons écrire un test paramétré fournissant plusieurs entrées et des valeurs de sortie attendues.

Dans l'exemple de code ci-dessus, vous pouvez voir ce qui suit:

1. Bloc «où» contenant les données pour le test à exécuter.
2. Le bloc «où» est le dernier bloc du test.
3. «Où» est combiné avec les autres blocs, c'est-à-dire donné, quand et alors.
4. La représentation des données est un format spécial appelé tableaux de données que nous examinerons en détail dans les prochaines sections de ce didacticiel.
5. La ligne d'en-tête de données est essentiellement les propriétés / variables d'entrée qui peuvent être directement utilisées dans le test. Par exemple. Reportez-vous à la déclaration dans le bloc 'quand' où nous avons directement utilisé entrée1 et entrée2 comme paramètres d'entrée sans les définir explicitement.

Utilisation des tables de données

Essayons maintenant de comprendre les tableaux de données en détail. Chaque ligne de la table de données représente les données d'un scénario individuel (exécution de test).

Par convention, c'est-à-dire que les valeurs d'entrée sont précédées d'un seul tube («|») tandis que les valeurs de sortie sont précédées d'un double tube («||»). Cela n’a aucune signification logique, mais c’est une convention et améliore la lisibilité. Ainsi, les deux exemples ci-dessous sont valables.

La ligne d'en-tête, comme indiqué ci-dessus, a un nom pour chacun des paramètres fournis en tant que données à tester. Il est important de noter ici que ces noms de paramètres ne doivent pas entrer en conflit avec des variables locales / globales existantes dans le test, sinon il y aura erreurs de compilation pour résoudre les noms de variables.

Un point important à noter lors de l'utilisation de tables de données est qu'un minimum de 2 colonnes est requis. Si vous avez juste besoin d'une colonne, une colonne vide avec des valeurs comme caractère de soulignement est une solution de contournement comme ci-dessous.

L'avantage de ce format est la simplicité, la lisibilité et l'extensibilité. L'ajout d'une nouvelle entrée de données est aussi simple que l'ajout d'une nouvelle ligne avec des valeurs de données.

Un autre point à noter ici est que les tables de données peuvent être utilisées pour contenir tout type de variables, classes, objets, énumérations, etc. qui le rendent encore plus puissant. Comme groovy est un langage typé facultativement, si un type explicite n'est pas spécifié, les variables de la table de données impliquent en fonction du type de données fournies.

Voyons un autre Exemple en utilisant des tables de données avec une liste de chaînes en entrée et en sortie en tant que nombre d'éléments dans la chaîne.

Dans l'exemple ci-dessus, vous pouvez remarquer que nous avons fourni une entrée sous forme de liste de tableaux de chaînes et que la sortie correspond à la taille de cette liste de tableaux. Ainsi, cela donne beaucoup de flexibilité pour avoir des données d'entrée de différents types.

Vous pouvez également simplement mentionner toutes les expressions qui renvoient des données du type d'entrée respectif et qui sont également utilisées directement dans les tables de données.

Cycle de vie du bloc «où»

Pour les tests contenant des échantillons de blocs where et de données sous forme de tableaux de données, chaque ligne de données représente une exécution de la méthode de test.

Par exemple, s'il y a 5 lignes de données et que le test contient des blocs «donné» et «quand», alors pour une telle ligne de données, les blocs de test seront exécutés une fois. Donc, dans l'ensemble, il y aura un total de 5 exécutions de la méthode de test.

Conseils & Astuces

Voyons quelques conseils et astuces pour les tests paramétrés tout en travaillant avec ces tables de données.

# 1) Affichage des résultats de l'exécution de chaque ligne séparément. Comme nous l'avons vu dans la section cycle de vie, pour chaque ligne de données, il y a une exécution du code de test. Afin d'obtenir ces lignes ou résultats affichés séparément pour chacune de ces lignes, l'annotation «@Unroll» peut être utilisée pour de tels tests.

Essayons de comprendre cela avec un exemple:

Nous utiliserons la même application de calculatrice avec 3 ensembles de données d'entrée fournis à la méthode testée.

sous-chaîne (0,0)

Sans l'annotation «@Unroll», voyons à quoi ressemble le résultat dans le terminal (ainsi que dans les rapports HTML). Avec ce type de sortie, il devient difficile de savoir quel jeu d'entrées a provoqué l'échec du test.

Voyons maintenant comment la sortie du test est rapportée séparément pour chaque ligne après avoir ajouté l'annotation '@Unroll' à la méthode de test (qui a des tables de données comme entrée de données).

#deux) Voyons maintenant comment ajouter des informations significatives à ces tests basés sur les données (au lieu de certains index ajoutés automatiquement comme dans la capture d'écran ci-dessus).

Nous pouvons utiliser des espaces réservés pour les propriétés d'entrée et de sortie (selon la table de données), puis nous pouvons voir les valeurs renseignées dans les noms de tests avec des données de tables de données.

Utilisons le même exemple et mettons à jour le nom du test pour obtenir les données de l'entrée et de la sortie attendue comme indiqué dans les tableaux de données:

Voyons maintenant à quoi ressemble la sortie dans le terminal et les rapports HTML:

Ainsi, comme vous pouvez le voir ici, les données d'entrée et de sortie s'affichent maintenant avec les noms des tests lorsqu'ils sont exécutés. De cette façon, cela facilite le dépannage et le débogage car il indique clairement quelle entrée a provoqué l'échec ou le mauvais comportement du test.

Conclusion

Dans ce tutoriel, nous avons appris à écrire des tests paramétrés avec le framework Spock. Nous avons également discuté de diverses caractéristiques des tableaux de données et de la manière dont ils peuvent être utilisés.

Consultez notre prochain tutoriel pour savoir comment utiliser les simulacres et les talons avec Spock !!

Tutoriel PREV | Tutoriel SUIVANT

lecture recommandée

• Ecrire des tests unitaires avec Spock Framework
• Questions d'entrevue Spock avec réponses (les plus populaires)
• Spock pour l'intégration et les tests fonctionnels avec sélénium
• Spock Mocking and Stubbing (Exemples avec des didacticiels vidéo)
• Tutoriel Spock: Test avec Spock et Groovy
• Framework basé sur les données dans Selenium WebDriver à l'aide d'Apache POI
• Comment effectuer des tests basés sur les données à l'aide de l'outil TestComplete
• Fonctionnement des tests pilotés par les données (exemples de QTP et de sélénium)