Didacticiel QF-Test

Ce chapitre décrit les différentes étapes nécessaires pour vous guider dans la création de votre première suite de test. L'application à tester est FileChooserDemo incluse dans le kit de développement logiciel Java. Elle est également incluse dans la distribution de QF-Test avec le code source, dans le répertoire QF-Test-2.0.1/doc/tutorial/FileChooserDemo

L'application FileChooserDemo est un très bon exemple sur la manière de personnaliser la classe FileChooser dans Swing, et de créer vos propres fichiers de dialogue Open, Save et personnalisés pour votre application. Nous l'utilisons comme le SUT (System Under Test) pour la création de votre propre suite de test.

Ce chapitre du didacticiel a été conçu de sorte à illustrer les concepts suivants :

Ouvrez une nouvelle (vide) suite de test dans QF-Test avec le menu File -> New Suite. Sachez que l'"ancienne" suite de test reste ouverte dans une fenêtre différente. Si vous venez juste de démarrer QF-Test (en cliquant sur l'icône du bureau ou en entrant QF-Test depuis une ligne de commande), vous verrez que vous avez déjà une suite de test vide sous vos yeux.

Assurez-vous que la vue détaillée est activée (menu View -> Show Details). Vous voyez maintenant la fenêtre divisée en deux avec un arbre du côté gauche et un volet du côté droit, représentant les détails du nSud sélectionné. L'arbre vous permet de naviguer parmi les nSuds de la suite de test ; lorsque vous sélectionnez un nSud, ses propriétés s'affichent sur le volet de droite.

Pour commencer vous devez démarrer votre application. Comme mentionné précédemment, l'application à tester est FileChooserDemo du kit de développement logiciel Java.

Pour cet exemple, nous commençons par insérer des éléments dans le nSud Extras de la suite de test. Cette zone est une sorte de bloc-notes dans laquelle nous pouvons expérimenter certains concepts avant de les placer dans la structure correcte de la suite de test. Quand vous ouvrez la branche du nSud Extras, vous voyez apparaître une fine ligne rouge juste après. Nous nous y référons comme un "marqueur d'insertion". Le but étant de vous faire savoir où le prochain nSud sera inséré si vous sélectionnez un élément depuis le menu Insert.

Remarque : Avant que vous n'insériez réellement le nSud pour démarrer le SUT, voici quelques explications sur le comportement de QF-Test lors de l'insertion de nSuds à la position du marqueur d'insertion. En fait, QF-Test vous laisse uniquement choisir des nSuds qui sont "autorisés" à être insérés à la position courante du marqueur. Aussi si par exemple vous sélectionnez le nSud racine de votre suite de test (en laissant la branche du nSud ouverte) et vous essayez d'insérer un nSud via le menu Insert, tous les choix sont désactivés mais seul le nSud Test de Sequences nodes est sélectionnable. Il y a d'autres restrictions avec d'autres types de nSuds (merci de vous référer au Manuel Utilisateur). Parfois vous serez surpris de voir qu'un nSud attendu ne peut pas être inséré, mais dans la plupart des cas cela est dû à une mauvaise position du marqueur d'insertion, parce que vous n'avez pas ouvert la branche du nSud parent pour insérer le nouveau nSud comme fils.

Remarque sur la version 2.0 : Un nouvel Assistant de Démarrage rapide est disponible dans QF-Test 2.0 pour simplifier le processus de création d'une séquence de démarrage de l'application. Vous pouvez ouvrir l'Assistant via le menu Extras -> Quickstart Wizard... et simplement suivre les étapes. Le remplissage manuel des attributs d'un noeud Start comme décrit dans les paragraphes suivants est toujours valide.

Pour démarrer l'application, utilisez le nSud Start Java SUT client. La capture d'écran suivante vous montre comment utiliser les menus contextuels, accessibles par un clic souris droit, pour insérer le nSud.

Après la sélection du nSud à insérer, une fenêtre de dialogue s'affiche, vous permettant de renseigner les propriétés du nSud :

Cliquez sur OK pour confirmer vos saisies dans la boîte de dialogue. Si tout marche correctement, vous voyez alors le nouveau nSud apparaître après le marqueur d'insertion dans la suite de test. Cliquez sur ce nouveau nSud (sélectionnez-le) et exécutez-le avec le bouton de rejeu . Vous verrez ensuite l'application FileChooserDemo apparaître sur votre écran :

Figure 3.3 - Fenêtre FileChooserDemo

Si l'application FileChooserDemo ne s'affiche pas au bout de quelques secondes, revenez aux étapes précédentes pour vous assurer que votre nSud Start Java SUT client a été correctement renseigné. Vous pouvez également jeter un coup d'Sil au Terminal, qui fournit des messages utiles au cas où quelque chose ne démarrerait pas.

3.3 Ajout d'un Test Flux de Saisie

Maintenant vous êtes prêt(e) à ajouter un Test Clickstream simple. Appuyez sur le bouton Démarrer l'enregistrement et passez sur la fenêtre de l'application du SUT. A partir de maintenant chaque action souris et clavier effectuée dans la fenêtre du SUT sera enregistrée. Cliquez sur différents boutons et revenez à la fenêtre de la suite de test dans QF-Test. Appuyez sur le bouton Arrêter l'enregistrement . Vous retrouverez la séquence enregistrée placée sous le nSud Extras sur le côté gauche de la fenêtre principale, comme montré ci-dessous :

Figure 3.4 - Flux de Saisie enregistré

Le nom de la séquence enregistrée sera entré de manière standard par QF-Test tout comme le temps et la date d'enregistrement. Vous pouvez changer ce nom en cliquant simplement sur le nSud et en changeant ses propriétés dans la vue détaillée.

Maintenant sélectionnez votre séquence enregistrée et exécutez-la avec le bouton de rejeu . Vous voyez maintenant votre séquence exacte d'événements souris et clavier rejouée dans la fenêtre du SUT. Bien sûr il vous faut redémarrer le SUT pour repartir à zéro.

Ce type de test peut être tout à fait spectaculaire et utilisé pour des démonstrations de votre application, mais il teste surtout l'implémentation sous-jacente Swing, et non pas la logique applicative. Dans les sections suivantes nous implémenterons des tests qui vérifient le contenu des champs et vérifient aussi les connexions causales dans le FileChooserDemo, mais tout d'abord nous allons structurer les séquences enregistrées dans une suite de test.

3.4 Construction d'une Suite de Test

La structure de base d'une suite de test est composée des nSuds suivants :

Remarque sur la version 2.0 : Dans QF-Test 2.0 il y a deux nouveaux types de noeuds pour faciliter la représentation et l'administration des tests logiques - "Test-case" et "Test-set". Ils ne sont pas expliqués dans ce tutoriel mais vous pouvez trouver une description détaillée dans le Chapitre 10.2 Gestion des Tests avec les Noeuds Test-set et Test-case ans le Manuel Utilisateur. QF-Test 2.0 apporte une autre nouvelle fonctionnalité, les "Dépendances" qui implémentent un mécanisme pour l'installation automatique et le nettoyage automatique de cas-tests. Merci de vous référer au Chapitre 11 Dépendances du Manuel Utilisateur.

Il y a quatre nSuds différents utilisés pour organiser une séquence : Test, Setup, Cleanup, et finalement le nSud général Sequence. Les tests sont implémentés avec le nSud test, les séquences spéciales Setup et Cleanup contiennent les étapes importantes pour s'assurer que le SUT s'exécute dans un état bien défini. Une mise en application courante de la paire Setup/Cleanup est de démarrer et d'arrêter l'application SUT, ainsi le SUT est toujours dans un état connu quand un test s'exécute. La paire Setup/Cleanup peut toutefois être utilisée à n'importe quel niveau et pour n'importe quel but jugé utile, comme ouvrir et fermer un dialogue par exemple.

Commençons par ajouter une séquence Setup à notre nSud test vide de premier niveau avec le menu Insert -> Sequence nodes -> Setup. La seconde étape consiste à déplacer le nSud Start Java SUT client depuis le nSud Extras (voir section précédente) et à le coller dans la séquence Setup.

Afin de déplacer ce nSud depuis Setup, vous devez tout d'abord vous assurer que le nSud Setup est ouvert (regardez à nouveau l'emplacement du marqueur d'insertion). Le déplacement du nSud Start Java SUT client peut désormais être effectué avec le menu contextuel (clic souris droit) ou avec les touches clavier Ctrl+X (couper) et Ctrl+V (coller).

Une fois fait, ajoutez un nSud Wait for client to connect avec le menu Insert -> Process nodes -> Wait for client. Ce nSud fait patienter QF-Test le temps que le client SUT démarre et s'assure de la connexion au SUT.

Nous avons besoin d'une chose supplémentaire pour que le nSud Setup soit complet. Après que le SUT se soit connecté à QF-Test, cela peut prendre un peu de temps avant que la première fenêtre ne s'affiche à l'écran. Nous devons nous assurer que le test ne démarre pas avant, aussi nous devons attendre que cette première fenêtre apparaisse.

A cette fin, insérez un nSud Wait for component après le nSud Wait for client avec le menu Insert -> Miscellaneous -> Wait for component. Si le SUT s'exécute, l'attribut Client doit être rempli avec le nom du client SUT, FileChooserDemo dans notre cas. Pour paramétrer l'ID du Composant, cliquez sur le bouton au-dessus du champ pour afficher une boîte de dialogue avec les nSuds Windows and components disponibles. Sélectionnez le nSud Window ayant pour étiquette JFrame frameFileChooserDemo.

Figure 3.5 - Dialogue de Sélection de Composant

Maintenant vous pouvez arrêter l'application FileChooserDemo et la relancer en exécutant le nSud Setup. Cela devrait vous donner :

Figure 3.6 - Séquence Setup de FileChooserDemo

L'étape suivante consiste à créer le nSud Sequence pour notre flux de saisie (clickstream). Vous devez fermer les branches du nSud Setup pour que le marqueur d'insertion soit placé après Setup, et non dedans. Alors vous pouvez déplacer votre séquence enregistrée du nSud Extras vers le marqueur d'insertion pour que le nSud Sequence apparaisse directement après la séquence Setup.

En dernier lieu vous pouvez créer une séquence Cleanup pour arrêter l'application. Cette séquence contient deux nSuds : un pour arrêter le client, et un autre pour s'assurer qu'il est bien terminé. Sur la figure ci-dessous, vous pouvez voir quels nSuds sont nécessairement mis en exécution pour cet exercice. Votre suite de test doit ressembler à ce qui suit :

Organisation de votre Suite de Test

Figure 3.7 - Organisation de votre Suite de Test

Vous venez d'effectuer les étapes les plus importantes de structuration de votre suite de test. Dans la section suivante, vous développerez votre suite de test en introduisant un contrôle sur un champ texte spécifique.

3.5 Ajout d'un Contrôle de Texte

Pour surveiller le comportement du client, nous utilisons des nSuds de contrôle, qui interrogent certains états et propriétés d'éléments dans le SUT. Le premier contrôle que nous introduirons est le Text-check (Contrôle de texte), qui vérifie qu'un champ texte contient la chaîne de caractère attendue. Notre contrôle sera effectué sur un bouton dans la fenêtre FileChooser.

Si le SUT n'est pas en exécution, démarrez-le maintenant en utilisant notre séquence Setup. Au sein de la fenêtre FileChooserDemo, cliquez sur le bouton Show FileChooser.

Pour commencer l'enregistrement d'un contrôle, cliquez le bouton d'enregistrement de contrôle (Record check) et passez sur la fenêtre FileChooser. Maintenant lorsque vous déplacez votre souris sur les composants, leur couleur est intervertie. Pour enregistrer le contrôle, allez au bouton Open, et faîtes un clic droit. Un menu contextuel s'affiche alors et vous donne le choix entre trois contrôles différents : Text, Enabled state et Geometry, comme l'illustre la figure ci-dessous :

Enregistrement d'un Contrôle dans la Fenêtre FileChooser

Figure 3.8 - Enregistrement d'un Contrôle dans la Fenêtre FileChooser

Choisissez Text dans le menu contextuel, retournez à la fenêtre de votre suite de test, et arrêtez l'enregistrement en cliquant sur le bouton d'arrêt .

Remarque : Au lieu de retourner à la suite de test pour activer le mode de contrôle en appuyant sur le bouton , vous pouvez également utiliser la touche F12 du clavier tout en restant dans la suite de test. Cette touche active/désactive le mode record check.

Ensuite, enregistrez une autre séquence flux de saisie arbitraire en utilisant le bouton , puis refermez la fenêtre FileChooser.

Maintenant vous savez comment organiser les séquences enregistrées dans votre test. Vous pouvez comparer vos résultats avec la manière dont nous avons organisé le test et renommé les séquences :

Figure 3.9 - Organisation du Test Text-Check dans l'Arbre

A ce stade, vous pouvez donner à votre test une exécution préliminaire. Arrêtez le client SUT s'il est exécution, cliquez sur le nSud test racine, et démarrez l'exécution en appuyant sur le bouton de rejeu .

Le résultat de l'exécution du test est alors stocké dans le run-log. Pour accéder au run-log, sélectionnez le menu Run -> Run log ou utilisez le raccourci clavier Ctrl+L.

Figure 3.10 - Run-Log de votre Test

Dans le run-log vous voyez comment la paire Setup/Cleanup est exécutée avant et après chaque test.

Dans ce test il n'y avait aucune erreur ou exception à l'exécution. Mais vous pouvez voir des cadres jaunes autour de certains nSuds, qui indiquent des avertissements. Dans le cas du FileChooser, ils sont dus à des composants qui n'ont pas de noms attribués. Vous trouverez plus de détails sur l'importance des noms de composants dans le Manuel Utilisateur.

A la fermeture de la fenêtre du run-log il vous est demandé si vous voulez enregistrer le run-log ; en effet, il est uniquement disponible jusqu'à ce que QF-Test soit fermé.

Maintenant modifions le test afin de créer une erreur dans le contrôle de texte. Cliquez sur le nSud Check-text afin de visualiser ses détails :

Figure 3.11 - Propriétés du NSud Check Text

Vous voyez ici que dans le champ Text une valeur a été saisie ("Open") qui représente la valeur à laquelle QF-Test s'attend. Changez ce texte par toute autre valeur arbitraire et relancez le test.

Maintenant lorsque vous rejouez le test, une boîte de dialogue apparaît à la fin indiquant qu'il y a eu "0 Exceptions, 1 Error, 0 Warnings."

Si vous ouvrez le run-log, vous voyez que des champs rouges entourent certains nSuds, indiquant que certaines erreurs se sont produites dans les nSuds fils. Vous pouvez utiliser le menu run-log Edit -> Find next error pour passer directement au nSud qui a causé l'erreur, ou utiliser le raccourci clavier Ctrl+N.

Maintenant nous allons développer notre suite de test pour y inclure un test qui vérifie la logique applicative du SUT.

3.6 Vérification de la Logique Applicative

Jusqu'ici nous nous sommes essentiellement concentrés sur l'implémentation Swing des fenêtres et des composants dans l'application SUT. Ce que nous n'avons pas encore abordé, c'est l'idée de tester la logique applicative réelle, ce qui sera donc l'objet de cette section.

Pour vérifier la logique applicative, il nous faut une relation causale entre certaines actions utilisateur qui génèrent une réaction de l'application. Dans le FileChooserDemo, nous avons mis une telle fonctionnalité qui illustre ce type de relation dans laquelle un champ texte change d'état - de désactivé à activé - sur le clic du bouton radio Custom (situé dans la partie gauche de la fenêtre).

Pour notre test, nous avons choisi d'enregistrer un flux de saisie qui active le champ texte, puis vérifie que le champ est réellement activé, et finalement réinitialise l'application par un clic sur le bouton Open. Cette séquence est un vrai test action-réaction de l'application puisque deux composants ne sont pas connectés dans Swing. Vérifiez que le contenu du champ texte n'est pas un test de la logique, mais de l'état initial de l'application complète.

Les étapes pour ce test sont très similaires à celles que vous avez suivies pour le test check text, avec la séquence flux de saisie et le contrôle enregistrés séparément. Notre solution suite de test est illustrée dans la figure ci-dessous :

Figure 3.12 - Test Contrôle de l'Etat Activé

Voici un résumé de ce que nous avons fait :


	DIDACTICIEL VERSION 2.0
SOMMAIRE	CHAPITRE 3 - CREATION D'UNE SUITE DE TEST
Introduction Suite de Test Exemple Création d'une Suite de Test Utilisation du Débogueur Ecriture d'une Procédure Création d'une Procédure Générale Modularisation Bibliothèque Standard Gestion de Composants d'IHM Complexes Avant de démarrer votre propre Application Lecture Avancée	Durée estimée : 30 à 45 minutes 3.1 Introduction 3.2 Démarrage de l'Application 3.3 Ajout d'un Test Flux de Saisie 3.4 Construction d'une Suite de Test 3.5 Ajout d'un Contrôle de Texte 3.6 Vérification de la Logique Applicative 3.1 Introduction Ce chapitre décrit les différentes étapes nécessaires pour vous guider dans la création de votre première suite de test. L'application à tester est FileChooserDemo incluse dans le kit de développement logiciel Java. Elle est également incluse dans la distribution de QF-Test avec le code source, dans le répertoire QF-Test-2.0.1/doc/tutorial/FileChooserDemo L'application FileChooserDemo est un très bon exemple sur la manière de personnaliser la classe FileChooser dans Swing, et de créer vos propres fichiers de dialogue Open, Save et personnalisés pour votre application. Nous l'utilisons comme le SUT (System Under Test) pour la création de votre propre suite de test. Ce chapitre du didacticiel a été conçu de sorte à illustrer les concepts suivants : Démarrage d'un SUT dans QF-Test Enregistrement de composants et organisation en des tests simples Création de tests vérifiant les dépendances des fonctions dans le SUT 3.2 Démarrage de l'Application Ouvrez une nouvelle (vide) suite de test dans QF-Test avec le menu File -> New Suite. Sachez que l'"ancienne" suite de test reste ouverte dans une fenêtre différente. Si vous venez juste de démarrer QF-Test (en cliquant sur l'icône du bureau ou en entrant QF-Test depuis une ligne de commande), vous verrez que vous avez déjà une suite de test vide sous vos yeux. Assurez-vous que la vue détaillée est activée (menu View -> Show Details). Vous voyez maintenant la fenêtre divisée en deux avec un arbre du côté gauche et un volet du côté droit, représentant les détails du nSud sélectionné. L'arbre vous permet de naviguer parmi les nSuds de la suite de test ; lorsque vous sélectionnez un nSud, ses propriétés s'affichent sur le volet de droite. Pour commencer vous devez démarrer votre application. Comme mentionné précédemment, l'application à tester est FileChooserDemo du kit de développement logiciel Java. Pour cet exemple, nous commençons par insérer des éléments dans le nSud Extras de la suite de test. Cette zone est une sorte de bloc-notes dans laquelle nous pouvons expérimenter certains concepts avant de les placer dans la structure correcte de la suite de test. Quand vous ouvrez la branche du nSud Extras, vous voyez apparaître une fine ligne rouge juste après. Nous nous y référons comme un "marqueur d'insertion". Le but étant de vous faire savoir où le prochain nSud sera inséré si vous sélectionnez un élément depuis le menu Insert. Remarque : Avant que vous n'insériez réellement le nSud pour démarrer le SUT, voici quelques explications sur le comportement de QF-Test lors de l'insertion de nSuds à la position du marqueur d'insertion. En fait, QF-Test vous laisse uniquement choisir des nSuds qui sont "autorisés" à être insérés à la position courante du marqueur. Aussi si par exemple vous sélectionnez le nSud racine de votre suite de test (en laissant la branche du nSud ouverte) et vous essayez d'insérer un nSud via le menu Insert, tous les choix sont désactivés mais seul le nSud Test de Sequences nodes est sélectionnable. Il y a d'autres restrictions avec d'autres types de nSuds (merci de vous référer au Manuel Utilisateur). Parfois vous serez surpris de voir qu'un nSud attendu ne peut pas être inséré, mais dans la plupart des cas cela est dû à une mauvaise position du marqueur d'insertion, parce que vous n'avez pas ouvert la branche du nSud parent pour insérer le nouveau nSud comme fils. Remarque sur la version 2.0 : Un nouvel Assistant de Démarrage rapide est disponible dans QF-Test 2.0 pour simplifier le processus de création d'une séquence de démarrage de l'application. Vous pouvez ouvrir l'Assistant via le menu Extras -> Quickstart Wizard... et simplement suivre les étapes. Le remplissage manuel des attributs d'un noeud Start comme décrit dans les paragraphes suivants est toujours valide. Pour démarrer l'application, utilisez le nSud Start Java SUT client. La capture d'écran suivante vous montre comment utiliser les menus contextuels, accessibles par un clic souris droit, pour insérer le nSud. Figure 3.1 - Insertion du NSud Start Java SUT Client Après la sélection du nSud à insérer, une fenêtre de dialogue s'affiche, vous permettant de renseigner les propriétés du nSud : Figure 3.2 - Propriétés du NSud Start Java SUT Client Les propriétés pour ce nSud sont décrites ci-après : Dans le champ Client vous entrez le nom pour le SUT qui sera utilisé comme référence à l'application par QF-Test. Vous pouvez donner au SUT le nom que vous voulez, mais le même nom sera utilisé pour référencer le SUT dans d'autres nSuds, aussi il vous faut constamment utiliser le nom choisi. Nous choisirons FileChooserDemo comme nom de client. Le second champ spécifie le programme exécutable qui sera utilisé pour implémenter le SUT. Pour notre exemple, la variable ${QF-Test:java} a été donnée, qui déclare de façon absolue que la Machine Virtuelle Java utilisée pour démarrer QF-Test est la même que celle utilisée pour démarrer le SUT. Le champ Directory détermine le répertoire personnel dans lequel le SUT sera démarré. Vous pouvez changer le répertoire en utilisant le bouton de sélection de répertoire (Select directory) ou en le saisissant manuellement. Le quatrième champ vous présente la classe de démarrage de votre application Java. Pour notre exemple, ce champ ne nécessite pas d'être renseigné, dans la mesure où le programme est dans une archive jar. Le démarrage de notre application sera implémenté avec la commande Java jar FileChooserDemo.jar. Aussi nous avons simplement besoin d'entrer cette commande comme un élément dans le champ Parameters. Toute entrée dans la table Parameters sera passée individuellement dans Java lors de l'exécution, aussi nous devons séparer les entrées. Les entrées peuvent être faîtes avec le bouton d'ajout de nouvelle ligne (Add new row) . Les champs restants de la boîte de dialogue des propriétés ne sont pas requis pour cet exemple. Le champ Comment en bas de la boîte de dialogue est utile, mais toujours facultatif. Cliquez sur OK pour confirmer vos saisies dans la boîte de dialogue. Si tout marche correctement, vous voyez alors le nouveau nSud apparaître après le marqueur d'insertion dans la suite de test. Cliquez sur ce nouveau nSud (sélectionnez-le) et exécutez-le avec le bouton de rejeu . Vous verrez ensuite l'application FileChooserDemo apparaître sur votre écran : Figure 3.3 - Fenêtre FileChooserDemo Si l'application FileChooserDemo ne s'affiche pas au bout de quelques secondes, revenez aux étapes précédentes pour vous assurer que votre nSud Start Java SUT client a été correctement renseigné. Vous pouvez également jeter un coup d'Sil au Terminal, qui fournit des messages utiles au cas où quelque chose ne démarrerait pas. 3.3 Ajout d'un Test Flux de Saisie Maintenant vous êtes prêt(e) à ajouter un Test Clickstream simple. Appuyez sur le bouton Démarrer l'enregistrement et passez sur la fenêtre de l'application du SUT. A partir de maintenant chaque action souris et clavier effectuée dans la fenêtre du SUT sera enregistrée. Cliquez sur différents boutons et revenez à la fenêtre de la suite de test dans QF-Test. Appuyez sur le bouton Arrêter l'enregistrement . Vous retrouverez la séquence enregistrée placée sous le nSud Extras sur le côté gauche de la fenêtre principale, comme montré ci-dessous : Figure 3.4 - Flux de Saisie enregistré Le nom de la séquence enregistrée sera entré de manière standard par QF-Test tout comme le temps et la date d'enregistrement. Vous pouvez changer ce nom en cliquant simplement sur le nSud et en changeant ses propriétés dans la vue détaillée. Maintenant sélectionnez votre séquence enregistrée et exécutez-la avec le bouton de rejeu . Vous voyez maintenant votre séquence exacte d'événements souris et clavier rejouée dans la fenêtre du SUT. Bien sûr il vous faut redémarrer le SUT pour repartir à zéro. Ce type de test peut être tout à fait spectaculaire et utilisé pour des démonstrations de votre application, mais il teste surtout l'implémentation sous-jacente Swing, et non pas la logique applicative. Dans les sections suivantes nous implémenterons des tests qui vérifient le contenu des champs et vérifient aussi les connexions causales dans le FileChooserDemo, mais tout d'abord nous allons structurer les séquences enregistrées dans une suite de test. 3.4 Construction d'une Suite de Test La structure de base d'une suite de test est composée des nSuds suivants : Les nSuds test racine contiennent un nombre arbitraire de nSuds séquences et tests. Remarque sur la version 2.0 : Les suites de test nouvellement créées dans QF-Test contiennent un nSud Test-set supplémentaire avec un nSud enfant Test-case. Procedures contient des séquences réutilisables qui peuvent être organisées en fonctions modulaires. Extras est le bloc-notes pour les expérimentations. Windows and components contiennent tous les éléments importants de la suite de test : les éléments enregistrés du SUT tels que les fenêtres, les menus et les boutons. Chaque élément au sein de la section Windows and components contient les propriétés de l'élément, pour que QF-Test puisse facilement trouver le composant lors du rejeu d'un test ou d'une séquence. Remarque sur la version 2.0 : Dans QF-Test 2.0 il y a deux nouveaux types de noeuds pour faciliter la représentation et l'administration des tests logiques - "Test-case" et "Test-set". Ils ne sont pas expliqués dans ce tutoriel mais vous pouvez trouver une description détaillée dans le Chapitre 10.2 Gestion des Tests avec les Noeuds Test-set et Test-case ans le Manuel Utilisateur. QF-Test 2.0 apporte une autre nouvelle fonctionnalité, les "Dépendances" qui implémentent un mécanisme pour l'installation automatique et le nettoyage automatique de cas-tests. Merci de vous référer au Chapitre 11 Dépendances du Manuel Utilisateur. Il y a quatre nSuds différents utilisés pour organiser une séquence : Test, Setup, Cleanup, et finalement le nSud général Sequence. Les tests sont implémentés avec le nSud test, les séquences spéciales Setup et Cleanup contiennent les étapes importantes pour s'assurer que le SUT s'exécute dans un état bien défini. Une mise en application courante de la paire Setup/Cleanup est de démarrer et d'arrêter l'application SUT, ainsi le SUT est toujours dans un état connu quand un test s'exécute. La paire Setup/Cleanup peut toutefois être utilisée à n'importe quel niveau et pour n'importe quel but jugé utile, comme ouvrir et fermer un dialogue par exemple. Commençons par ajouter une séquence Setup à notre nSud test vide de premier niveau avec le menu Insert -> Sequence nodes -> Setup. La seconde étape consiste à déplacer le nSud Start Java SUT client depuis le nSud Extras (voir section précédente) et à le coller dans la séquence Setup. Afin de déplacer ce nSud depuis Setup, vous devez tout d'abord vous assurer que le nSud Setup est ouvert (regardez à nouveau l'emplacement du marqueur d'insertion). Le déplacement du nSud Start Java SUT client peut désormais être effectué avec le menu contextuel (clic souris droit) ou avec les touches clavier Ctrl+X (couper) et Ctrl+V (coller). Une fois fait, ajoutez un nSud Wait for client to connect avec le menu Insert -> Process nodes -> Wait for client. Ce nSud fait patienter QF-Test le temps que le client SUT démarre et s'assure de la connexion au SUT. Nous avons besoin d'une chose supplémentaire pour que le nSud Setup soit complet. Après que le SUT se soit connecté à QF-Test, cela peut prendre un peu de temps avant que la première fenêtre ne s'affiche à l'écran. Nous devons nous assurer que le test ne démarre pas avant, aussi nous devons attendre que cette première fenêtre apparaisse. A cette fin, insérez un nSud Wait for component après le nSud Wait for client avec le menu Insert -> Miscellaneous -> Wait for component. Si le SUT s'exécute, l'attribut Client doit être rempli avec le nom du client SUT, FileChooserDemo dans notre cas. Pour paramétrer l'ID du Composant, cliquez sur le bouton au-dessus du champ pour afficher une boîte de dialogue avec les nSuds Windows and components disponibles. Sélectionnez le nSud Window ayant pour étiquette JFrame frameFileChooserDemo. Figure 3.5 - Dialogue de Sélection de Composant Maintenant vous pouvez arrêter l'application FileChooserDemo et la relancer en exécutant le nSud Setup. Cela devrait vous donner : Figure 3.6 - Séquence Setup de FileChooserDemo L'étape suivante consiste à créer le nSud Sequence pour notre flux de saisie (clickstream). Vous devez fermer les branches du nSud Setup pour que le marqueur d'insertion soit placé après Setup, et non dedans. Alors vous pouvez déplacer votre séquence enregistrée du nSud Extras vers le marqueur d'insertion pour que le nSud Sequence apparaisse directement après la séquence Setup. En dernier lieu vous pouvez créer une séquence Cleanup pour arrêter l'application. Cette séquence contient deux nSuds : un pour arrêter le client, et un autre pour s'assurer qu'il est bien terminé. Sur la figure ci-dessous, vous pouvez voir quels nSuds sont nécessairement mis en exécution pour cet exercice. Votre suite de test doit ressembler à ce qui suit : Figure 3.7 - Organisation de votre Suite de Test Vous venez d'effectuer les étapes les plus importantes de structuration de votre suite de test. Dans la section suivante, vous développerez votre suite de test en introduisant un contrôle sur un champ texte spécifique. 3.5 Ajout d'un Contrôle de Texte Pour surveiller le comportement du client, nous utilisons des nSuds de contrôle, qui interrogent certains états et propriétés d'éléments dans le SUT. Le premier contrôle que nous introduirons est le Text-check (Contrôle de texte), qui vérifie qu'un champ texte contient la chaîne de caractère attendue. Notre contrôle sera effectué sur un bouton dans la fenêtre FileChooser. Si le SUT n'est pas en exécution, démarrez-le maintenant en utilisant notre séquence Setup. Au sein de la fenêtre FileChooserDemo, cliquez sur le bouton Show FileChooser. Pour commencer l'enregistrement d'un contrôle, cliquez le bouton d'enregistrement de contrôle (Record check) et passez sur la fenêtre FileChooser. Maintenant lorsque vous déplacez votre souris sur les composants, leur couleur est intervertie. Pour enregistrer le contrôle, allez au bouton Open, et faîtes un clic droit. Un menu contextuel s'affiche alors et vous donne le choix entre trois contrôles différents : Text, Enabled state et Geometry, comme l'illustre la figure ci-dessous : Figure 3.8 - Enregistrement d'un Contrôle dans la Fenêtre FileChooser Choisissez Text dans le menu contextuel, retournez à la fenêtre de votre suite de test, et arrêtez l'enregistrement en cliquant sur le bouton d'arrêt . Remarque : Au lieu de retourner à la suite de test pour activer le mode de contrôle en appuyant sur le bouton , vous pouvez également utiliser la touche F12 du clavier tout en restant dans la suite de test. Cette touche active/désactive le mode record check. Ensuite, enregistrez une autre séquence flux de saisie arbitraire en utilisant le bouton , puis refermez la fenêtre FileChooser. Maintenant vous savez comment organiser les séquences enregistrées dans votre test. Vous pouvez comparer vos résultats avec la manière dont nous avons organisé le test et renommé les séquences : Figure 3.9 - Organisation du Test Text-Check dans l'Arbre A ce stade, vous pouvez donner à votre test une exécution préliminaire. Arrêtez le client SUT s'il est exécution, cliquez sur le nSud test racine, et démarrez l'exécution en appuyant sur le bouton de rejeu . Le résultat de l'exécution du test est alors stocké dans le run-log. Pour accéder au run-log, sélectionnez le menu Run -> Run log ou utilisez le raccourci clavier Ctrl+L. Figure 3.10 - Run-Log de votre Test Dans le run-log vous voyez comment la paire Setup/Cleanup est exécutée avant et après chaque test. Dans ce test il n'y avait aucune erreur ou exception à l'exécution. Mais vous pouvez voir des cadres jaunes autour de certains nSuds, qui indiquent des avertissements. Dans le cas du FileChooser, ils sont dus à des composants qui n'ont pas de noms attribués. Vous trouverez plus de détails sur l'importance des noms de composants dans le Manuel Utilisateur. A la fermeture de la fenêtre du run-log il vous est demandé si vous voulez enregistrer le run-log ; en effet, il est uniquement disponible jusqu'à ce que QF-Test soit fermé. Maintenant modifions le test afin de créer une erreur dans le contrôle de texte. Cliquez sur le nSud Check-text afin de visualiser ses détails : Figure 3.11 - Propriétés du NSud Check Text Vous voyez ici que dans le champ Text une valeur a été saisie ("Open") qui représente la valeur à laquelle QF-Test s'attend. Changez ce texte par toute autre valeur arbitraire et relancez le test. Maintenant lorsque vous rejouez le test, une boîte de dialogue apparaît à la fin indiquant qu'il y a eu "0 Exceptions, 1 Error, 0 Warnings." Si vous ouvrez le run-log, vous voyez que des champs rouges entourent certains nSuds, indiquant que certaines erreurs se sont produites dans les nSuds fils. Vous pouvez utiliser le menu run-log Edit -> Find next error pour passer directement au nSud qui a causé l'erreur, ou utiliser le raccourci clavier Ctrl+N. Maintenant nous allons développer notre suite de test pour y inclure un test qui vérifie la logique applicative du SUT. 3.6 Vérification de la Logique Applicative Jusqu'ici nous nous sommes essentiellement concentrés sur l'implémentation Swing des fenêtres et des composants dans l'application SUT. Ce que nous n'avons pas encore abordé, c'est l'idée de tester la logique applicative réelle, ce qui sera donc l'objet de cette section. Pour vérifier la logique applicative, il nous faut une relation causale entre certaines actions utilisateur qui génèrent une réaction de l'application. Dans le FileChooserDemo, nous avons mis une telle fonctionnalité qui illustre ce type de relation dans laquelle un champ texte change d'état - de désactivé à activé - sur le clic du bouton radio Custom (situé dans la partie gauche de la fenêtre). Pour notre test, nous avons choisi d'enregistrer un flux de saisie qui active le champ texte, puis vérifie que le champ est réellement activé, et finalement réinitialise l'application par un clic sur le bouton Open. Cette séquence est un vrai test action-réaction de l'application puisque deux composants ne sont pas connectés dans Swing. Vérifiez que le contenu du champ texte n'est pas un test de la logique, mais de l'état initial de l'application complète. Les étapes pour ce test sont très similaires à celles que vous avez suivies pour le test check text, avec la séquence flux de saisie et le contrôle enregistrés séparément. Notre solution suite de test est illustrée dans la figure ci-dessous : Figure 3.12 - Test Contrôle de l'Etat Activé Voici un résumé de ce que nous avons fait : La première séquence clique le bouton Custom, activant ainsi le champ texte. La seconde séquence vérifie que le champ texte est réellement actif. Merci de noter également qu'ici il n'y a pas de connexion directe dans Swing entre le bouton et le champ texte, ainsi nous testons bien la logique applicative. La troisième séquence réinitialise l'application en appuyant sur le bouton Open. Ce chapitre du didacticiel étant clos, nous allons maintenant nous concentrer sur le diagnostic d'erreurs en présentant plus en détail le débogueur de QF-Test.

	QF-Test est une marque de Quality First Software GmbH. Kapitec Software SAS est le Distributeur Français de QF-Test. Ce didacticiel a été traduit de l'anglais par Kapitec Software SAS (Novembre 2005). Date de mise à jour : 14-Mai-2007