Tests unitaires
Une mauvaise configuration des règles dans une application peut entraîner des retards dans le traitement des dossiers. Lorsqu’une erreur se produit, il est possible que des dossiers doivent être réaffectés par les utilisateurs ou réparés par un administrateur. Prenons par exemple le cas d’un dossier qui doit être routé au service de gestion des commandes. Si le dossier est routé à la place au service de la comptabilité, un comptable doit le rediriger vers le service de gestion des commandes. Le comptable perd du temps à rerouter la tâche (assignment) tandis que le service de gestion des commandes n’a pas de dossier à traiter. La réaffectation du dossier entraîne donc un retard pour le client.
Pour éviter les erreurs de configuration telles que des tâches mal routées, les développeurs testent leurs applications. La façon la plus simple de tester une application est d’effectuer des tests unitaires (unit testing) sur des règles individuelles. Les tests unitaires permettent la livraison continue des applications en contrôlant la qualité des plus petites unités de fonctionnalité. Dans une application Pega, l’unité la plus petite est une règle individuelle.
Le but des tests unitaires est de vérifier que chaque élément de l’application, par exemple une table de décision ou une report definition, fonctionne comme prévu. Le test unitaire réduit le risque de voir une erreur de configuration dans une règle se propager à d’autres règles de l’application et entraîner des retards importants dans le traitement des dossiers.
Utilisez les tests unitaires pour limiter les erreurs de configuration. En effectuant des tests unitaires des règles individuelles, vous vous assurez que chaque règle fonctionne comme prévu lors de sa configuration. Prenons l’exemple d’un arbre de décision qui évalue une propriété. Comme le montre l’image suivante, l’application lit la propriété à partir d’une data page issue d’une report definition. Si l’arbre de décision (decision tree) renvoie un résultat incorrect alors que la data page contient les bonnes données, vous pouvez déterminer que l’erreur provient de l’arbre de décision.
Vérifiez vos connaissances avec l’interaction suivante.
Test unitaire de règles individuelles
Vous pouvez tester une règle avec des données de test que vous indiquez en cliquant sur Actions > Run dans la barre d’outils du formulaire de règles dans Dev Studio.
Note: Pour certains types de règles, comme celles relatives aux fichiers binaires, Pega ne propose pas d’option de test unitaire. Si la règle ne peut pas faire l’objet d’un test unitaire, l’option Run n’apparaît pas.
L'affichage de la fenêtre Run Rule varie selon le type de règle. Par conséquent, l'exécution d'une règle varie selon son type. En général, cependant, les règles sont exécutées en utilisant les données d’une page de test que vous définissez.
Lorsque vous exécutez la règle, le système utilise la résolution de règle. Si vous soumettez une règle à un test unitaire et qu'il existe une version supérieure de la règle, le système exécute la version supérieure de la règle.
Enregistrer un test unitaire pour les tests automatisés
Une fois le test exécuté, vous pouvez également le convertir en dossier de test réutilisable que vous pouvez exécuter à tout moment. Un dossier de test identifie une ou plusieurs conditions vérifiables qui permettent de déterminer si une règle renvoie un résultat attendu. La création d’un dossier de test réutilisable prend en charge le modèle de livraison continue, en offrant un moyen périodique de tester les règles afin d’identifier les effets des règles nouvelles ou modifiées. Exécutez un dossier de test chaque fois qu’une modification du code pourrait affecter une fonctionnalité existante. Pour plus d'informations sur l'utilisation des dossiers de test unitaire, consultez la rubrique Understanding unit test cases de Pega Community.
Tip: Vous pouvez automatiquement exécuter un test unitaire enregistré à partir de la règle ou du test unitaire à l’aide de la fonction de test PegaUnit.
Pour créer un dossier de test, vous devez convertir un test dans la fenêtre Run Rule et définir les résultats indiquant un test unitaire abouti. Chaque résultat attendu consiste en une assertion qui décrit une ou plusieurs conditions à tester, ainsi que le résultat attendu pour chaque condition. Les dossiers de test prennent en charge plusieurs types d'assertions conçus pour tester divers aspects de l'exécution des règles. Les assertions disponibles pour un dossier de test varient selon le type de règle testé.
Note: Pour une explication complète concernant les types d’assertions pris en charge et leur utilisation, consultez l’article de Pega Community intitulé Defining expected test results with assertions.
Quelques exemples d’assertions et de différentes façons dont elles peuvent être utilisées sont fournis dans le tableau suivant :
| Type d’assertion | Utilisation | Exemple |
|---|---|---|
| Propriété (property) | Teste la valeur de la propriété spécifiée. Nécessite la page sur laquelle la propriété est définie, une opération de comparaison et une valeur de comparaison. | pxUrgencyWork est égal à 10 |
| Résultat de décision (decision result) | Teste la valeur renvoyée par une règle de décision. Nécessite des valeurs pour chaque propriété d’entrée requise par la règle de décision afin de renvoyer le résultat attendu. | Quand Referred by employee est faux, renvoyer RecruitingWB |
| Temps d’exécution prévu (expected run time) | Teste si une règle s’exécute dans un laps de temps autorisé. Nécessite une opération de comparaison et une durée autorisée exprimée en secondes. | Le temps d’exécution attendu est inférieur ou égal à trois secondes. |
| Page | Vérifie la présence d’une page en mémoire. Nécessite le nom de la page ainsi qu’une opération de comparaison. | La page D_CoursesList ne contient aucune erreur. |
Lorsque vous avez obtenu l’ensemble des résultats escomptés, enregistrez la configuration du dossier de test. Vous pouvez accéder à un dossier de test enregistré à partir de la règle. La règle répertorie tous les dossiers de test enregistrés pour cette règle ainsi que le statut de chaque dossier de test en fonction de sa dernière exécution. Si vous exécutez à nouveau un dossier de test et qu'il échoue, ouvrez le résultat et identifiez chaque assertion qui a renvoyé un résultat inattendu. Si un dossier de test renvoie les résultats attendus, le statut Passed s’affiche en vert.
Vous pouvez grouper des dossiers de tests unitaires dans une suite de test afin d’exécuter des dossiers de tests et des suites de test dans un ordre déterminé. Lorsque vous exécutez des suites de test en bloc, le traitement se fait séquentiellement et non en parallèle.
Préparer des dossiers de test
L’enregistrement d’un dossier de test nécessite l’accès à un ruleset configuré pour stocker les dossiers de test. Vous ne pouvez pas enregistrer de dossiers de test dans un ruleset qui n’a pas été configuré pour stocker des dossiers de test.
Avant d’enregistrer un test unitaire, rapprochez-vous de votre administrateur système pour identifier un ruleset configuré pour stocker les dossiers de test. Veillez attentivement à la portabilité et à l’indépendance des tests, car ils ne doivent ni dépendre d’un autre dossier de test ni interférer avec des tests ultérieurs. Lorsque l’application de développement est déployée dans l’environnement de production, vous pouvez migrer l’application sans inclure les dossiers de test.
Tip: Utilisez la fonction Cleanup pour restaurer une page système de clipboard ou pour rétablir un changement survenu dans les données ou les instances de travail pendant l’exécution du test. L’onglet History restitue l’historique des modifications.
Exécuter un dossier de test
Dans Dev Studio, la page d’accueil Unit testing répertorie tous les dossiers de test définis pour une application donnée, en indiquant le statut de chaque dossier de test à l’issue de sa dernière exécution. Dans la page d’accueil, vous pouvez également créer des suites de test composées d’un ou plusieurs dossiers de test connexes. Les suites de dossiers de test unitaire de Pega exécutent plusieurs dossiers de test dans l’ordre que vous avez indiqué.
Tip: Dans le menu Configure , sélectionnez Application > Quality > Automated Testing > Unit Testing pour accéder à la page d’accueil.
Vérifiez vos connaissances avec l’interaction suivante.
Bonnes pratiques pour la configuration des tests unitaires
Les tests unitaires automatisés produisent des résultats exploitables. Par ailleurs, l’exécution et la gestion d’un test automatique prennent moins de temps qu’un test manuel. Veillez à ce que le test soit mis au point en même temps que les règles de votre application Pega Platform™. Vous pouvez décider de réutiliser des dossiers de test durant le développement continu, tandis que les autres équipes peuvent exploiter vos suites de test.
Quand créer des tests unitaires automatisés
Lorsqu’un test renvoie un résultat attendu, il convient de configurer un test unitaire automatisé comme le suggère la table des priorités ci-dessous.
| Priorité élevée | Priorité faible |
|---|---|
| Tests ayant des résultats prévisibles | Tests soumis à des modifications fréquentes nécessitant une maintenance des dossiers de test |
| Tests qui doivent être exécutés fréquemment | Tests faciles à tester manuellement |
| Tests qui allègent l’effort personnel lors des tests de logique complexe | Tests trop complexes pour être automatisés |
| Tests contenant des règles largement utilisées au sein de l’application | Tests contenant une persistance de données extraites d’une base de données |
Tip: Nous vous recommandons d’exécuter des tests à chaque fusion et enregistrement au minimum, et dans l’idéal de façon plus fréquente et régulière.
Développer pour la couverture
Dans la mesure où vos tests unitaires couvrent un large éventail de scénarios, assurez-vous que les validations créées suffisent pour couvrir tous les scénarios positifs et négatifs. L’objectif est d’avoir une couverture de règle aussi étendue que possible, et d’inclure différents chemins pour l’exécution d’une règle. Ajoutez suffisamment de tests de façon à couvrir toutes les combinaisons d’entrée et de sortie, mais veillez à ce que la logique du dossier de test soit brève et lisible afin d’optimiser sa réutilisation. Il est plus facile de repérer rapidement les problèmes de règle, et d’en améliorer la conception et la maintenance lorsque les tests unitaires sont petits.
Note: Pour en savoir plus sur la mesure de la couverture d’un test de règle, consultez la rubrique Academy Test coverage.
Développer pour la maintenance
Chaque dossier de test doit être facile à lire et à assimiler par quiconque. Par exemple, attribuez à vos dossiers de test des noms et des descriptions qui illustrent bien leur objet. Commentez chaque étape pour les rendre encore plus compréhensibles et faciliter leur maintenance.
Rendez les données de test aussi modulaires que possible afin de faciliter et de fluidifier les mises à jour et les modifications ultérieures. Inutile, par exemple, de créer des données de test pour l’application dans son ensemble, ou pour des structures de données vastes ou complexes. Les données de test modulaires ont la particularité de permettre les petites modifications qui n’exigent pas de reconfigurer toutes les données de test et qui ne risquent pas de créer des problèmes avec d’autres tests.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?