Skip to main content

Tests unitaires

Effectuer des 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, 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.

error_customer_delay

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 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. 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. En effectuant des tests unitaires des règles individuelles lors de leur configuration, vous vous assurez que chaque règle fonctionne comme prévu. Si l’arbre de décision 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.

isolate_cause_of_error

Vérifiez vos connaissances avec l’interaction suivante.

Exécution de tests unitaires sur des règles d’application

Réalisez les tâches suivantes pour effectuer un test unitaire sur une règle :

  • Ouvrez la fenêtre Run Rule à partir du formulaire de règle.
  • Initialisez la règle avec les données de test.
  • Affichez le résultat renvoyé par la règle.

Ouvrir la fenêtre Run Rule à partir du formulaire de règle

Pour procéder à un test unitaire sur une règle, ouvrez le formulaire de règle et exécutez la règle. Pour certains types de règles, comme celles relatives aux fichiers binaires, Pega Platform 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.

Affichage de la fenêtre Run Rule

L’affichage de la fenêtre Run Rule varie selon le type de règle testé. Par exemple, les règles de data page et les règles when utilisent une boîte de dialogue similaire à celle du clipboard. Pour plus de détails sur le test unitaire d’un type de règle spécifique, consultez l’article de Pega Community intitulé Test unitaire de règles individuelles.

Si la règle peut être appliquée à des données en mémoire, Pega Platform affiche la fenêtre Run Rule. Par exemple, comme les declare expressions, les règles de décision et les règles d’interface utilisateur fonctionnent sur des données en mémoire, Pega Platform affiche la fenêtre Run Rule.

Les report definitions ne peuvent être appliquées qu’au contenu d’une table de base de données, et non à des données en mémoire. Par conséquent, Pega Platform n’affiche pas la fenêtre Run Rule et renvoie les données du rapport lorsque vous exécutez une report definition.

Initialiser la règle avec les données de test

Dans la fenêtre Run Rule, identifiez une page de test de données utilisée pour le test unitaire de la règle. La fenêtre Run Rule crée la page de test dans le clipboard. Le nom de la page de test est le même que celui de la classe Applies To de la règle, auquel on ajoute le préfixe temp_. Cela permet d’isoler les données de test des autres pages en mémoire.

Lorsque vous procédez au test unitaire d’une règle, déterminez la façon dont vous voulez obtenir les données sources pour la page de test. La fenêtre Run Rule comporte plusieurs options pour ajouter des données à la page de test, selon le type de règle testé.

Généralement, vous pouvez créer une page de données de test à l’aide d’un data transform. Par défaut, Pega Platform applique le data transform pyDefault pour renseigner la page de test. Vous pouvez également sélectionner un autre data transform à appliquer. Par exemple, pour procéder au test unitaire d’une table de décision, vous pouvez créer un data transform afin de fournir des valeurs pour les propriétés évaluées par la table, plutôt que d’avoir à saisir manuellement des valeurs lorsque vous exécutez la règle.

Vous pouvez également copier une page de la classe appropriée déjà présente dans le clipboard. Par exemple, pour tester une table de décision utilisée par un type de dossier, vous pouvez créer un dossier et copier les données à partir de pyWorkPage.

Afficher le résultat renvoyé par la règle

Après avoir sélectionné une méthode pour renseigner la page de test, réinitialisez la page pour remplir les données et exécutez la règle pour renvoyer un résultat.

Tip: La fonction Reset Page permet d’effacer les résultats d’un test précédent.

Si la règle accepte des entrées, vous pouvez saisir les valeurs à tester. Les valeurs que vous saisissez remplacent celles de la page de test. Par exemple, prenons la table de décision ToEmployeeReferralWB représentée dans l’image suivante. La table de décision détermine la liste des tâches en attente (work queue) vers laquelle router une tâche. Si la valeur de la propriété Referred by employee est True, alors l’application route la tâche vers la liste des tâches en attente ReferralWB.

Decision table referred by

Pour une table ou un arbre de décision, attribuez des valeurs à chaque propriété d’entrée et exécutez à nouveau pour afficher le résultat de la table ou de l’arbre de décision. L’image suivante montre le résultat du test lorsque .ReferredByEmployee est sur True.

test_results_referral_rule_compressed

Vous pouvez également consulter le résultat du test unitaire via le clipboard. La fenêtre Run Rule génère plusieurs pages dans le clipboard. Ces pages fournissent des informations sur le test des règles.

RuleToRun Correspond à la version de la règle testée qui est stockée dans le clipboard. S’il existe plusieurs versions de la règle dans l’application, consultez cette page pour identifier la version de la règle testée.
temp_ page

Elle est créée ou copiée lorsque vous testez une règle. Les noms de ces pages commencent par la chaîne temp_. Consultez cette page pour examiner les données utilisées pour initialiser la règle du test unitaire.

Vérifiez vos connaissances avec l’interaction suivante.

Vérifiez vos connaissances avec l’interaction suivante.

Enregistrer un test unitaire pour les tests automatisés

Une fois que vous avez effectué avec succès un test unitaire sur une règle, vous pouvez créer un dossier de test basé sur le résultat du test. 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 de tester les règles sur une base récurrente afin d’identifier les effets des règles nouvelles ou modifiées.

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. Définissez les résultats attendus devant indiquer si un test unitaire a réussi ou non. Chaque résultat attendu consiste en une assertion qui décrit une ou plusieurs conditions à tester. 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é.

Pour une explication complète concernant les types d’assertions pris en charge et leur utilisation, consultez l’article de Pega Community intitulé Définition des résultats de test attendus avec des assertions.

Quelques exemples d’assertions et les différentes façons dont elles peuvent être utilisées sont fournis dans le tableau suivant :

Type d’assertion Utilisation Exemple
Propriété 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 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 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.

Vérifiez vos connaissances avec l’interaction suivante.

Bonnes pratiques pour la configuration des tests unitaires

Enregistrer le dossier de test

L’enregistrement du dossier de test nécessite l’accès à un ruleset configuré pour stocker les dossiers de test. Si le ruleset que vous sélectionnez n’est pas configuré pour stocker les dossiers de test, Pega Platform renvoie une erreur. Avant d’enregistrer un test unitaire, rapprochez-vous de votre administrateur système pour identifier un ruleset configuré pour stocker les dossiers de test.

Sauvegardez les dossiers de test dans un ruleset de test dédié à la maintenance et au packaging. Pour faciliter la configuration, utilisez une application basée sur l’application de développement et incluez un ruleset conçu spécifiquement pour les dossiers de test. 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.

Exécuter le dossier de test

Dans Dev Studio, la page d’accueil Unit testing répertorie tous les dossiers de test définis pour une application ainsi que le statut de chaque dossier de test en fonction de sa dernière exécution. Dans la page d’accueil, vous pouvez également créer des suites de dossiers 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.

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

40% found this content useful

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice