Création d'une Procédure Générale
Gestion de Composants d'IHM Complexes
Avant de démarrer votre propre Application
8.3 Paquetage Utilitaire Case à cocher
8.5 Paquetage Utilitaire Menu Contextuel
8.6 Paquetage Utilitaire Tableau
8.7 Paquetage Utilitaire Texte
8.8 Paquetage Utilitaire Arbre
8.9 Paquetage Utilitaire Sélecteur de Fichiers
8.10 Paquetage Utilitaire OptionPane
Nous finissons sur le thème de la modularisation dans ce nouveau chapitre en présentant une bibliothèque standard de fonctions utilitaires. Vous vous êtes déjà familiarisé(e) avec certains de ces utilitaires, comme les opérations pour traiter les cases à cocher. D'autres utilitaires restent à découvrir. Les sections qui suivent traitent en détail de chacune de ces opérations.
Il y a plusieurs choses à apprendre de ce chapitre. Mais surtout, vous verrez une bibliothèque d'utilitaires exploitables. En fait, la bibliothèque a évolué à partir d'une bibliothèque très similaire utilisée pour les tests de régression de qftestJUI chez Quality First Software GmbH. En étudiant les opérations de cette bibliothèque, cela vous donnera des idées sur la manière d'améliorer la modularisation de vos propres suites de test, et donc de simplifier le processus global de test.
Les procédures dans cette bibliothèque doivent fonctionner avec n'importe quelle application Java/Swing standard ; elles ont été conçues indépendamment de n'importe quel SUT spécifique. Aussi elles doivent s'adapter aux besoins de votre SUT. La bibliothèque est contenue dans le fichier qfs.qft et est incluse dans la distribution de qftestJUI.
En complément de la description fournie dans ce didacticiel, vous pouvez trouver la documentation HTML de la bibliothèque standard au format javadoc. Le fichier qfs.html se trouve dans le répertoire qftestJUI-1.08.6/include.
Comme nous l'avons déjà mentionné, la bibliothèque standard que nous introduisons ici n'est pas spécifique au SUT. Cependant, pour des raisons de démonstrations dans ce didacticiel, nous utiliserons une application spécifiquement conçue pour être utilisée avec la bibliothèque standard.
Affichez la suite de test StdLibDemo.qft, se trouvant dans le répertoire qftestJUI-1.08.6/doc/tutorial du répertoire d'installation qftestJUI. Vous devez voir :
Figure 8.1 - Suite de Test StdLibDemo.qft
Démarrez l'application SUT en exécutant le nSud Setup. Après quelques instants, la fenêtre du SUT doit apparaître. Si ce n'est pas le cas, c'est qu'elle est probablement cachée derrière la suite de test.
Figure 8.2 - SUT pour le Test de la Bibliothèque Standard
Chargez le fichier de la suite de test qfs.qft, qui se trouve dans le répertoire qftestJUI-1.08.6/include d'installation de qftestJUI.
Ici nous avons un aperçu des paquetages disponibles :
Figure 8.3 - Bibliothèque Standard
La suite contient principalement des procédures pour traiter des composants Java/Swing. Nous y avons également inclus le paquetage cleanup, qui est utile pour gérer les effets d'exceptions inattendues se produisant dans une suite de test. Dans un premier temps, nous allons traiter du paquetage swing, et ensuite revenir à cleanup.
Dans toutes les procédures de cette bibliothèque, vous remarquerez que la variable $(client) est référencée. C'est un mécanisme standard que vous verrez souvent répété dans beaucoup de suites de test pour créer l'indépendance depuis un SUT spécifique. Ici, la bibliothèque suppose que la suite de test utilise la bibliothèque qui positionnera une valeur pour $(client) avant d'utiliser une procédure. Par exemple, ici nous voyons les propriétés du nSud racine Test-suite de la suite StdLibDemo.qft, dans lequel nous positionnons la valeur $(client) comme une variable de suite. Ainsi, tout nSud exécuté pour cette suite de test (tels que les appels de procédure à qfs.qft) auront accès à la variable.
Figure 8.4 - Paramétrage de la Variable $(client)
Vous pourriez aussi positionner la valeur $(client) par appel à une procédure dans qfs.qft. Un tel schéma peut être utile lorsque vous avez plus d'un SUT. Sachez que qfs.qft ne peut pas avoir de valeur par défaut positionnée pour la variable $(client) car cela le lierait à un SUT spécifique. Il vous appartient de positionner une valeur à la variable $(client) pour la bibliothèque standard à utiliser !
Vous avez certainement remarqué sur la figure ci-dessus que nous avons inclus qfs.qft dans la suite de test de démonstration sans aucune référence directe au répertoire dans lequel le fichier se trouve. La raison est que le répertoire /include de la distribution qftestJUI a été ajouté à qftestJUI comme un chemin de bibliothèque implicite pour toutes vos suites de test. Cela signifie concrètement que tout fichier suite de test situé dans ce répertoire peut être inclus dans votre propre suite de test.
Pour d'autres chemins de bibliothèque, référez-vous aux options globales de qftestJUI via le menu : Edit -> Options -> General -> Library.
8.3 Paquetage Utilitaire Case à cocher
Nous commençons par regarder le paquetage qfs.swing.checkbox, qui est un bon point de départ. Les procédures ici devraient vous être familières si vous avez développé la suite de bibliothèque utils.qft décrite au Chapitre 7.
Les procédures disponibles dans ce paquetage sont :
- select : Sélectionne (coche) une case à cocher. Si la case à cocher est déjà sélectionnée, alors aucune action ne sera prise.
- deselect : Dessélectionne (décoche) une case à cocher. Si la case à cocher est déjà dessélectionnée, alors aucune action ne sera prise.
- set : Paramètre une case à cocher dans un état donné (vrai ou faux).
Pour chacune de ces procédures, vous passez l'ID du composant case à cocher comme un argument de variable. La bibliothèque prend en charge la vérification de l'état de la case à cocher, à savoir si elle a été ou non correctement paramétrée tel q'attendu. Pour voir l'usage de ces procédures, regardez dans le nSud Checkbox Tests de StdLibDemo.qft.
Figure 8.5 - Exemple d'Utilisation du Paquetage qfs.swing.checkbox
L'utilisation des autres procédures dans ce paquetage suit le modèle général vu ici.
Le paquetage qfs.swing.menu vous permet de sélectionner facilement des items et des items de cases à cocher depuis les menus ou les sous-menus. Les procédures visibles après l'ouverture du noeud paquetage sont :
- selectItem : Sélectionne un item depuis un menu.
- selectSubItem : Sélectionne un item depuis un sous-menu.
- setCheckItem : Paramètre l'état d'un item de menu de case à cocher (vrai ou faux).
- setSubCheckItem : Paramètre l'état d'un item de case à cocher depuis un sous-menu (vrai ou faux).
Pour chacune de ces procédures, vous devez passer l'ID composant des menus comme l'item et/ou le sous-item pour sélectionner ou cocher : l'utilisation diffère légèrement selon la nature de la procédure. Regardez l'exemple d'utilisation du nSud Menu Tests. Par exemple, un appel à setSubCheckItem ressemble à :
Figure 8.6 - Exemple d'Appel à qfs.swing.menu.setSubCheckItem
Ici nous voyons les arguments de variable requis pour implémenter l'appel à la procédure. Ces arguments sont organisés ainsi :
menu -> item -> subCheckItem (checkItemValue)
qui représente l'implémentation suivante dans le SUT :
Options -> Tree -> Enable (true)
Clearer peut être le processus réel comme vu dans le SUT :
Figure 8.7 - Sélection d'un Item de Sous-Menu Check dans le SUT
8.5 Paquetage Utilitaire Menu Contextuel
Les menus contextuels sont similaires à des menus normaux car ils contiennent des items, des sous-menus et des menus cases à cocher. La principale différence est le moyen par lequel le menu contextuel est invoqué, c'est-à-dire par un clic droit sur un composant qui a été configuré pour afficher un menu contextuel.
Le paquetage qfs.swing.popupmenu contient les mêmes procédures que qfs.swing.menu ; seule l'implémentation diffère. Pour chaque procédure, votre suite de test doit en premier prendre soin d'ouvrir le menu contextuel avant d'appeler une procédure depuis le paquetage popupmenu, car un menu contextuel est un composant spécifique. Tenez compte de l'exemple suivant comme montré dans le SUT :
Figure 8.8 - Sélection d'un Item de Sous-Menu de Case à cocher dans un Menu Contextuel
Nous avons implémenté cet exemple au travers du test suivant dans StdLibDemo.qft. Le premier nSud affiche le menu contextuel, et alors l'appel à la procédure est fait, suivi par un contrôle des résultats.
Figure 8.9 - Exemple d'Appel à qfs.swing.popupmenu.setSubCheckItem
8.6 Paquetage Utilitaire Tableau
Le paquetage qfs.swing.table fournit des procédures utilitaires pour les tableaux. Actuellement il ne contient qu'une seule procédure pour vous aider à redimensionner la largeur d'une colonne d'un tableau. Les valeurs relatives et absolues de largeur sont possibles.
- ResigeColumn : Redimensionne la largeur d'une colonne d'un tableau. Le truc dans l'implémentation est le nSud Fetch Geometry qui récupère la largeur de la colonne active. L'action de redimensionnement est effectuée en glissant la souris vers la gauche ou la droite.
8.7 Paquetage Utilitaire Texte
Le paquetage qfs.swing.text fournit des procédures utilitaires pour les text fields et les text areas, un besoin que vous avez certainement déjà eu lors du développement de suites de test.
- clearField : Efface un text field. Cette procédure ne peut pas être utilisée avec un text area.
- clearArea : Efface un text area. Cette procédure ne peut pas être utilisée avec un text field.
Remarque : Ces procédures sont maintenant presque superflues, parce que les nSuds Text input peuvent effacer le composant cible si nécessaire. Cependant, les procédures peuvent encore servir.
Pour chacune de ces procédures, passez simplement l'ID du composant text field/area. Ici nous voyons un test dans StdLibDemo.qft qui se sert du composant text area dans le SUT. Dans ce test, nous effaçons d'abord le text area et nous saisissons deux lignes de texte. Alors le text area est vérifié pour confirmer qu'il contient le texte attendu. Ensuite, nous effaçons à nouveau le text area et nous vérifions qu'il est vide.
Figure 8.10 - Exemple d'Utilisation de qfs.swing.text.clearArea
8.8 Paquetage Utilitaire Arbre
Nous avons fourni quelques procédures simples d'accès pour manipuler des arbres dans le paquetage qfs.swing.tree. Cela inclut :
- collapse : Ferme un nSud d'un arbre.
- expand : Ouvre un nSud d'un arbre.
Pour n'importe laquelle de ces procédures, vous passez simplement l'ID du composant du nSud que vous voulez manipuler. Par exemple, ici nous voyons un appel à la procédure pour ouvrir un nSud arbre :
Figure 8.11 - Exemple d'Utilisation de qfs.swing.tree.expand
Remarquez que dans cet exemple, nous utilisons un composant d'un nSud arbre que nous avons enregistré plus tôt. Si vous regardez dans le nSud Windows and components de la suite de test StdLibDemo.qft, vous verrez les composants Item tree individuels que nous avons enregistrés :
Figure 8.12 - Items Composant d'Arbre
8.9 Paquetage Utilitaire Sélecteur de Fichiers
Le paquetage qfs.swing.filechooser est légèrement différent des procédures utilitaires que nous avons jusqu'à présent vues. Ce paquetage est destiné non seulement à aider à manipuler tout dialogue de sélecteur de fichiers (le composant Swing JFileChooser), mais également à enregistrer et à identifier des composants de cette fenêtre de dialogue. Nous listerons d'abord les procédures, puis nous entrerons dans le détail :
- selectFile : Sélectionne un fichier dans une fenêtre de dialogue sélecteur de fichier.
- enableNameResolver : Installe le solveur de noms du JFileChooser.
- disableNameResolver : Désinstalle le solveur de noms du JFileChooser.
La première procédure (selectFile) est simple et directe. Vous fournissez simplement le nom du fichier qui sera entré dans text field file name du dialogue. Votre suite de test doit en premier gérer l'ouverture du dialogue. Par exemple :
Figure 8.13 - Exemple d'Utilisation de qfs.swing.filechooser.selectFile
Toutefois, utiliser selectFile ne fonctionnera pas jusqu'à ce que votre suite de test autorise le solveur de noms ! Nous y venons.
La procédure enableNameResolver installe et permet une extension à qftestJUI appelé le JFileChooserResolver. Ce solveur de noms vous aidera énormément pour faire face aux imperfections du dialogue Java JFileChooser. C'est un NameResolver standard comme l'explique le chapitre intitulé Name Resolver Hooks dans le Manuel de Référence Technique.
Ce qui est intéressant avec JFileChooser c'est que les composants dans les dialogues standards (et en effet la fenêtre de dialogue elle-même) n'ont pas été nommés avec l'opération Java setName. Cela peut porter à confusion lors du développement de suites de test, comme les mêmes composants apparaissent dans différentes fenêtres de dialogue. Par exemple, le text field File Name sera visible à la fois dans le dialogue de sélecteur de fichier Save et Open.
Pour qftestJUI ce n'est pas un problème. qftestJUI dispose de puissants algorithmes pour enregistrer et identifier des composants, et il ne devrait donc pas confondre un composant sans nom et non unique qui apparaît dans plusieurs fenêtres. La confusion sera la plupart du temps en terme de gestion de composants pour le développeur de suites de test. Regardez la liste de composants enregistrés pour les deux dialogues de sélecteur de fichiers Open et Save pour l'application Demo :
Figure 8.14 - Composants et Dialogues JFileChooser Enregistrés
Comme vous pouvez le voir, qftestJUI a correctement identifié les composants et leur a donné à chacun un nom unique, tel que textFile_Name:2 - qui représente le second du même composant de ce type qui a été vu. Imaginez maintenant que vous avez beaucoup d'autres types de dialogue JFileChooser, et chacun avec sa propre liste de composants devant être maintenus séparément. Ecrire des suites de test sous ce type d'environnement peut rapidement devenir lourd.
Saisissez le name resolver. C'est une fonctionnalité qui permet à qftestJUI d'attribuer des noms à des composants sans nom d'un dialogue JFileChooser comme s'ils avaient été nommés dans le code source Java original en utilisant setName. Le résultat est que le JFileChooser et ses composants peuvent être traités de façon générique. Vous aurez juste besoin d'une liste de composants pour n'importe quel nombre de dialogue JFileChooser devant être manipulés dans votre suite de test. Voici un exemple d'utilisation :
Figure 8.15 - Utilisation du Solveur de Noms
Nous voyons dans l'implémentation de SelectFile que les composants génériques sont référencés :
Figure 8.16 - Implémentation du selectFile avec les Composants Génériques
En effet pour votre propre suite de test, vous ne devriez pas avoir à maintenir des composants pour les dialogues JFileChooser, si vous utilisez le solveur de noms. Les composants génériques sont stockés dans qfs.qft :
Figure 8.17 - Composants FileChooser Génériques dans qfs.qft
Veuillez noter que dans notre suite de test de démonstration StdLibDemo.Qft, le solveur de noms est permis et neutralisé pendant l'installation et le nettoyage. C'est abusé et seulement fait pour les besoins de la démonstration. Vous devriez seulement avoir besoin d'activer le solveur de noms une fois dans votre suite de test et de le laisser tel quel. Il n'est pas utile de neutraliser le solveur de noms après qu'il ait été autorisé.
8.10 Paquetage Utilitaire OptionPane
Le paquetage qfs.swing.optionpane contient des procédures utilitaires solveur de noms similaires à celles décrites dans le dernier chapitre. JOptionPane est le composant Swing utilisé pour créer ces petites boîtes de messages informant l'utilisateur d'erreurs de programme, avertissement ou demande de confirmation.
Le besoin de solveur de noms pour ce composant résulte du fait que ni le dialogue, ni ses sous-composants (boutons de confirmation et étiquettes de texte de message), ne sont nommés. Aussi qftestJUI doit les identifier sur la base de leurs titres ou de leurs étiquettes de texte, ce qui résulte en la création de divers nSuds composant pour chaque instance de JOptionPane. Ceci peut générer un grand nombre de ces éléments , ce qui n'est donc pas souhaitable dans un souci de clarté et de maintenabilité.
Maintenant regardons les procédures d'interface. Elles sont très simples :
- enableNameResolver : Installe le solveur de noms JOptionPane.
- disableNameResolver : Désinstalle le solveur de noms JoptionPane.
La procédure enableNameResolver installe et permet une extension à qftestJUI appelé JOptionPaneResolver. Ce solveur de noms facilite la manipulation de dialogues JOptionPane. C'est un NameResolver standard, comme expliqué dans le Manuel de Référence Technique.
Il est en général suffisant d'installer le NameResolver une fois au début de l'exécution du test, par exemple directement après le nSud Wait for client to connect. Généralement, la désinstallation n'est pas nécessaire.
Comme mentionné ci-dessus, des composants génériques pré-définis sont fournis dans qfs.qft, ce qui vous évite alors de maintenir les vôtres. La figure suivante les montre :
Figure 8.18 - Composants OptionPane Génériques dans qfs.qft
La figure vous montre que 5 types de dialogue OptionPane sont supportés :
- Erreur
- Information
- Avertissement
- Question
- Texte simple (Plain)
A titre d'exemple le nSud composant plain dialog a été ouvert pour vous montrer son contenu. Il contient des nSuds pré-définis pour les différents boutons possibles (boutons standards et personnalisés) et étiquettes, contenant généralement le texte du message
Dans notre suite de test de démonstration StdLibDemo.qft vous pouvez trouver un petit test pour ce solveur de noms dans le nSud test OptionPane qui teste les deux dialogues About disponibles dans le menu Help de la Demo. Vous voyez un test avec le solveur de noms et un autre sans. Regardez les composants sous Windows and components utilisés pour ce test. Sans le solveur de noms installé, alors deux composants légèrement différents doivent être maintenus. En utilisant le solveur de noms seul un des composants pré-définis de qfs.qft est requis.
Remarque : L'implémentation du solveur de noms décrit dans ce chapitre doit pouvoir mapper la plupart des occurrences des composants JOptionPane aux composants prédéfinis dans qfs.qft. Cependant, il peut y avoir des instances de JOptionPane avec des composants personnalisés à l'intérieur, ayant pour résultat l'enregistrement séparé de représentations de composants.
Pour finir, nous traitons du paquetage qfs.cleanup, qui est utile pour le nettoyage générique de l'environnement SUT après qu'une exception inattendue se soit produite. Imaginons, par exemple, qu'une exception soit générée lors d'une tentative de manipulation d'un menu dans le SUT. L'exception provoquera la redirection d'un chemin d'exécution dans votre suite de test vers un gestionnaire d'exception, ou la gestion d'une exception "implicite". Cela signifie que le flux normal d'exécution qui aurait dû fermer correctement le menu ouvert est maintenant interrompu. Sans action appropriée, ce menu pourrait rester ouvert et ainsi bloquer d'autres événements dirigés vers le SUT.
Voici une liste des procédures disponibles dans ce paquetage :
- closeAllModalDialogs : S'assure que les fenêtres de dialogue modales du SUT sont fermées.
- closeAllMenus : Ferme tous les menus du SUT inconditionnellement.
- implicitExceptionHandler : Utilise comme un gestionnaire générique pour traiter implicitement des exceptions capturées.
Les premières procédures doivent être relativement claires aussi bien en terme de significations que d'objectifs. La procédure implicitExceptionHandler en fait inclut l'utilisation des autres procédures dans ce paquetage, ce qui en fait un bon gestionnaire par défaut pour votre suite de test si des exceptions inattendues surgissent.
Le concept de la gestion implicite d'exception est un concept important, et nous allons y consacrer le reste de cette section. Si vous regardez dans les propriétés de n'importe quel nSud Test, vous verrez une case à cocher intitulée implicitly catch exceptions.
Figure 8.19 - Test Configuré pour Capturer Implicitement des Exceptions
Avec cette fonctionnalité activée dans un test, une exception qui se produit et qui n'est pas capturée explicitement dans un nSud Catch sera à la place redirigée vers le nSud Cleanup du nSud Test. Sans une capture implicite, une exception non capturée arrêtera l'exécution de la suite de test.
Les règles pour la gestion d'exceptions implicites sont simples : si une exception est générée et n'est pas capturée, alors qftestJUI cherche le nSud test parent suivant qui a été configuré pour capturer implicitement les exceptions. Il est donc possible de configurer une hiérarchie de gestion de capture implicite.
Remarque : Si un nSud Test gère implicitement une exception, son état final sera paramétré à Exception pour le refléter. L'erreur sera dûment reportée pour être sûr que l'exception ne passe pas inaperçue.
Dans StdLibDemo.qft nous voyons un exemple d'un test qui est configuré pour capturer implicitement des exceptions et dans lequel plusieurs exceptions inattendues se produisent. Le test est sans sens, mais il est utile dans ce cas puisqu'il illustre parfaitement cette fonctionnalité. Ici, nous produisons les erreurs en laissant ouverts les dialogues modales et les menus, puis en essayant de cliquer sur la fenêtre principale du SUT, générant ainsi une exception car étant bloquée par le dialogue modal ou le menu.
Figure 8.20 - Exemples d'Erreur Implicite
Exécutez le test. Avant de commencer, désactivez temporairement l'option Edit -> Options -> Debugger -> Break on uncaught exception. Autrement le débogueur s'ouvrira indépendamment de l'état Implicitly catch exceptions. Ce qui est intéressant à voir c'est le comportement, quand le drapeau Implicitly catch exceptions n'est pas coché, ou en neutralisant simplement l'appel à implicitExceptionHandler. Comme c'est souvent le cas, la vraie compréhension provient d'une première prise en main associée à des informations techniques (comme c'est le cas de ce document), c'est pourquoi nous vous encourageons à essayer ce test et les autres tests dans la suite de test pour visualiser par vous-même le comportement .
qftestJUI est une marque de Quality First Software GmbH. Kapitec Software SAS est le Distributeur Français de qftestJUI.
Ce didacticiciel a été traduit de l'anglais par Kapitec Software SAS (Novembre 2005). Date de mise à jour : 06-Oct-2006