Présentation
Ce guide d'utilisation de l'outil offre une vue d'ensemble des quatre tâches principales liées au test d'unité
effectuées à l'aide de Rational QualityArchitect :
-
Test d'unité
-
Test de scénario
-
Génération de modules de remplacement
-
Enregistrement de session EJB
Il est risqué de proposer un processus de développement dans lequel les tests sont repoussés jusqu'à ce que tous les
composants puissent être assemblés en un système complet. Les incidents détectés aussi tard dans le cycle de vie seront
plus difficiles à résoudre et plus susceptibles de créer des retards importants, en particulier si la résolution de
certains problèmes architecturaux demande une re-conception conséquente.
Même si la confiance de l'équipe dans la qualité des composants de son système est raisonnablement élevée, le niveau de
fiabilité général du système peut rester inacceptable. Imaginez par exemple un système simple formé de cinq composants,
le niveau de fiabilité de chacun d'entre eux (noté au moyen de la métrique de couverture de test ou de méthodes moins
quantitatives) s'élevant à 95%. La fiabilité du système étant cumulative, la notation générale est de 95% x 95% x 95% x
95%x 95%, soit seulement plus de 77%. Tandis que la probabilité de rencontrer des problèmes n'est que de 1 sur 20 pour
chacun des composants, elle est quasiment de 1 sur 4 pour le système général, et ce, alors que les composants sont
relativement peu nombreux.
Au contraire, un processus de développement qui intègre les tests de composant tout au long d'un processus itératif
présente plusieurs avantages importants :
-
Les problèmes peuvent être détectés et résolus dans un contexte isolé, ce qui facilite non seulement leur
résolution, mais également leur détection et leur diagnostic.
-
Le test et le développement étant étroitement liés tout au long du cycle de vie, les mesures de la progression s'en
trouvent plus crédibles (mesurer la progression ne consiste plus seulement à mesurer la part de produit codée, mais
aussi celle qui est en fonctionnement).
-
Les entorses au planning causées par l'apparition de problèmes imprévus s'en trouvent réduites, ce qui rend le
planning général plus réaliste et réduit les risques du projet.
Bien que l'anticipation des tests apporte des avantages considérables, cette pratique est loin d'être établie, en
particulier en ce qui concerne les composants middle-tier, sans interface utilisateur graphique.
Pour quelle raison ? Parce qu'elle est longue et fastidieuse et que, par le passé, les coûts engendrés par la
résolution de ces problèmes pratiques ont fréquemment dépassé les avantages. De plus, la plupart des tests étant
spécialement conçus pour un composant particulier, les possibilités de réutilisation sont faibles. De nombreuses
organisations reconnaissent que le fait de construire des routines de test et des modules de remplacement à partir de
zéro, pour les jeter ensuite après chaque projet, représente une grande perte de temps et d'argent. Elles préfèrent
consacrer leurs ressources limitées à d'autres domaines.
QualityArchitect rend l'anticipation des tests absolument faisable, grâce à la génération automatique des routines de
test et des modules de remplacement ; cette génération ne s'effectue pas une fois pour toutes, mais de manière
incrémentielle, à mesure que le modèle évolue tout au long du développement. Tout le processus de développement devient
plus structuré, mesuré et visible, car les résultats des tests de composant offrent des critères d'entrée plus
convaincants permettant d'éviter les tests système prématurés. QualityArchitect permet aux développeurs de se consacrer
aux aspects créatifs de la définition de tests, et de passer plus de temps à réfléchir au meilleur moyen de tester un
composant, plutôt qu'à écrire et à déboguer des modules de remplacement et des pilotes de test. Les développeurs et les
architectes travaillent en proche collaboration sur les modèles visuels partagés. Ce faisant, ils créent naturellement
une relation plus productive entre eux.
Ce guide d'utilisation de l'outil est applicable sous Windows 98/2000/NT 4.0.
Etapes outil
Ce guide d'utilisation de l'outil couvre les principales tâches relatives à l'implémentation d'un test de composant
automatisé à l'aide de QualityArchitect :
-
Etapes préalables au test d'unité
-
Implémenter un test d'unité
-
Implémenter un test de scénario
-
Créer un module de remplacement
-
Utiliser l'enregistreur de session EJB
Pour générer tout test à l'aide de QualityArchitect, tant pour les composants COM que pour les composants EJB, il est
nécessaire de créer et de configurer un projet Rational avec l'outil Rational Administrator. Ce projet doit comporter
un magasin de données de test pour contenir tous les actifs de test, tels que les résultats et les groupes de données
de test. Vous en trouverez la description dans le Guide d'utilisation de l'outil : Configuration de projets à l'aide de
Rational Administrator.
L'objectif d'un test d'unité est de confirmer qu'une certaine opération sur un certain composant donne la valeur de
retour correcte pour un certain ensemble d'entrées. Les tests d'unité sont créés en-dehors de la spécification des
classes dans la vue logique. Le processus de création et d'exécution d'un test d'unité comprend trois étapes :
-
Génération du code du test d'unité
-
Génération des données du test d'unité
-
Exécution du test et examen des résultats
Génération du code du test d'unité
Le code du test d'unité contient toutes les instructions nécessaires à l'instanciation du composant, à l'appel de
l'opération à tester et à la confrontation du résultat par rapport à une référence.
Pour les composants COM
-
Sélectionnez l'opération à tester sous l'interface du composant dans la vue logique.
-
Cliquez avec le bouton droit sur l'opération figurant sous l'interface du composant et sélectionnez Rational
Test > Generate Unit Test (Générer un test d'unité). Au cours de cette procédure, vous pouvez être invité et
amené à vous connecter à un projet Rational.
En sortie, QualityArchitect génère un code compatible avec Visual Basic 6.
Depuis Visual Basic, vous devez d'abord essayer de compiler le code. Chaque erreur de compilation doit être examinée.
Dans certaines circonstances, QualityArchitect ne sera pas en mesure de générer un code pour tester les opérations qui
utilisent beaucoup de types de données complexes. Si tel est le cas, QualityArchitect insérera un code invalide qui, au
moment où il devra se compiler, mettra en surbrillance les segments de code nécessitant un codage manuel. Une fois que
le code se compile, vous pouvez passez à l'étape suivante : Génération des données du
test d'unité.
Pour les composants EJB
-
Sélectionnez l'opération à tester depuis l'interface distante dans la vue logique.
-
Cliquez avec le bouton droit sur l'opération et sélectionnez Rational Test > Select Unit Test Template
(Sélectionner un canevas de test d'unité).
-
Rendez-vous dans le canevas approprié pour votre serveur EJB. Pour WebSphere, sélectionnez
websphere_remote.template dans le dossier EJBWebSphereBusiness Methods. Pour Web Logic, sélectionnez
weblogic_remote.template dans le dossier EJBWeb LogicBusiness Methods.
-
Sélectionnez Rational Test > Generate Unit Test (Générer un test d'unité). Au cours de cette procédure,
vous pouvez être invité et amené à vous connecter à un projet Rational.
En sortie, QualityArchitect générera un code Java.
Vous pouvez utiliser l'environnement de développement intégré (IDE) ou l'éditeur de votre choix pour examiner le
code Java. L'éditeur R2, livré avec l'outil Rational Rose, peut être utilisé à cette fin.
Une fois dans votre éditeur, vous pouvez d'abord essayer de compiler le code. Chaque erreur de compilation doit être
examinée. Dans certaines circonstances, QualityArchitect ne sera pas en mesure de générer un code qui utilise beaucoup
de types de données complexes. Si tel est le cas, QualityArchitect insérera un code invalide qui ne se compilera pas,
afin d'indiquer les lignes de code où un codage manuel est requis. Une fois que le code se compile, vous pouvez passez
à l'étape suivante : Génération des données du test d'unité.
La vraie mesure d'un test d'unité réussi réside dans les données de test. Le code de test, lui, est entièrement
jetable, puisque QualityArchitect peut régénérer le code à tout moment. Si QualityArchitect peut créer le code de test,
pour autant, il ne peut créer des données de test pertinentes. C'est à l'analyste ou à l'implémenteur de s'en charger.
Celui-ci doit s'efforcer de créer des données de test qui valident des tests positifs et négatifs représentatifs. Les
données de test qui se concentrent sur les conditions frontière de la logique du composant sont d'excellentes
candidates au test d'unité.
Pour les composants COM
-
Sélectionnez l'opération à tester sous l'interface du composant dans la vue logique.
-
Cliquez avec le bouton droit sur cette opération et sélectionnez Rational Test > Create Datapool (Créer
un groupe de données).
-
Une fois que vous avez sélectionné Create Datapool (Créer un groupe de données), une boîte de dialogue
Datapool Properties (Propriétés du groupe de données) s'affiche. Vous pouvez alors sélectionner Edit Datapool
Data (Editer les données du groupe de données) pour commencer à entrer les données, ou Define Datapool
Fields (Définir les zones du groupes de données) pour que QualityArchitect génère les données de test pour
vous.
Pour les composants EJB
-
Sélectionnez l'opération à tester depuis l'interface distante dans la vue logique.
-
Cliquez avec le bouton droit sur l'opération figurant sous l'interface distante et sélectionnez Rational Test >
Create Datapool (Créer un groupe de données).
-
Une fois que vous avez sélectionné Create Datapool (Créer un groupe de données), une boîte de dialogue
Datapool Properties (Propriétés du groupe de données) s'affiche. Vous pouvez alors sélectionner Edit Datapool
Data (Editer les données du groupe de données) pour commencer à entrer les données, ou Define Datapool
Fields (Définir les zones du groupes de données) pour que QualityArchitect génère les données de test pour
vous.
Si vous sélectionnez Define Datapool Fields (Définir les zones du groupe de données), vous pourrez utiliser les
fonctions de génération de données de test dont dispose QualityArchitect. Cet outil peut générer divers types de
données génériques, spécifiés dans la boîte à liste déroulante de la zone Type.
Après avoir choisi les types appropriés, sélectionnez le nombre de lignes à générer et cliquez sur Generate Data
(Générer des données). Il est presque certain que QualityArchitect ne sera pas en mesure de générer toutes les données
à votre place. Par exemple, QualityArchitect pourra générer une liste générique de villes, mais pas une liste de
numéros de facture valides, spécifiques à un système de bons de commande. Ces données doivent être entrées manuellement
en tant que type de données ou directement dans un groupe de données. Dès qu'un type de données a été créé avec des
données personnalisées, QualityArchitect peut générer ce type depuis l'interface Define Datapool Fields (Définir les
zones du groupe de données), ce qui rend cette option très intéressante. En revanche, si vous entrez les données
directement dans un groupe de données, elles ne seront disponibles que pour ce groupe particulier.
Lorsque vous sélectionnez Edit Datapool Data (Editer les données du groupe de données), vous allez directement
saisir des données de test pertinentes. Il existe une zone par argument, une zone pour un retour attendu et une zone
pour une erreur attendue. Lorsque vous spécifiez une erreur, le numéro d'erreur et les messages textuels d'erreur sont
tous deux des entrées valides. Si votre opération nécessite un objet complexe en tant qu'argument, ou si elle doit
renvoyer un objet complexe, vous ne pourrez insérer cette référence objet dans le groupe de données. Fractionnez alors
votre objet de manière à obtenir les types d'argument simples requis pour la construction d'une instance de l'objet. A
cet effet, utilisez les boutons Insert Before (Insérer avant) et Insert After (Insérer après) pour
ajouter des zones au groupe de données. Vous devrez modifier le code du test pour construire une instance de l'objet
avec les données fournies.
Exécution du test et examen des résultats
Après avoir créé le code et les données du test, vous êtes prêts à exécuter ce dernier. Vous pouvez l'exécuter depuis
l'IDE ou le planifier dans une suite TestManager. Voir Guide d'utilisation de l'outil : Exécution d'une suite de tests à l'aide
de Rational TestManager pour plus d'informations à ce sujet.
-
Au début de l'exécution du test, vous êtes invité à choisir un emplacement pour journaliser les résultats. Une fois
que vous avez spécifié un emplacement, TestManager y consigne les résultats de l'exécution du test.
-
Au terme de l'exécution, TestManager affiche le journal de test. Pour visualiser les résultats de votre test,
sélectionnez l'onglet Detailed View (Vue détaillée) de la fenêtre Log Viewer (Afficheur de journal).
Développez l'arborescence des résultats pour voir les détails de l'exécution du test. Pour obtenir plus
d'informations, cliquez avec le bouton droit sur une ligne quelconque et sélectionnez Properties
(Propriétés).
L'objectif d'un test de scénario est de confirmer qu'une certaine série d'opérations effectuées sur une certaine série
de composants se combinent de manière à accomplir correctement une tâche collective. Les tests de scénario sont créés à
partir de diagrammes d'interaction, plus précisément de diagrammes de collaboration et de séquence. Le processus de
création et d'exécution d'un test d'unité comprend ces trois étapes :
-
Génération du code du test de scénario
-
Génération des données du test de scénario
-
Exécution du test et examen des résultats
Génération du code du test de scénario
Le code du test de scénario comprendra tout le code de pilote de test nécessaire à l'instanciation des composants, à
l'appel des opérations testées et à l'évaluation de ces dernières à l'aide de points de vérification. Les points de
vérification désignent un mécanisme qui permet au code de test d'exécuter des instructions SQL sur une base de données,
afin de vérifier que la manipulation sous-jacente des données est correcte.
Pour les composants EJB
-
Sélectionnez le diagramme de collaboration dans le navigateur.
-
Cliquez avec le bouton droit sur le diagramme et sélectionnez Rational Test > Select ScenarioTest
Template (Sélectionner un canevas ScenarioTest).
-
Rendez-vous dans le canevas approprié pour votre serveur EJB. Pour WebSphere, sélectionnez
websphere_scenario.template dans le dossier EJBWebSphereScenario. Pour Web Logic, sélectionnez
weblogic_scenario.template dans le dossier EJBWeb LogicScenario.
-
Ouvrez la séquence ou le diagramme de collaboration qui modélise le scénario testé. Il est important de spécifier
des messages pour les composants du diagramme qui seront testés. Pour spécifier ces messages, effectuez un
double-clic sur la ligne de message et spécifiez un nom dans la boîte à liste déroulante de l'onglet General
(Général). Ce nom doit correspondre à l'opération testée. Par la suite, ces spécifications peuvent être modifiées
de manière à inclure les données de jeu d'essai.
Par exemple, Rose indiquera par défaut cette spécification de message :
getTransactions(customerID : String)
Cette spécification peut être modifiée comme suit, de manière à inclure un seul cas de donnée :
getTransactions(customerID : String="BBryson")
Pour chaque test de scénario, QualityArchitect génère automatiquement un groupe de données pour les données
de jeu d'essai. Les données du diagramme sont insérées dans la première ligne. Vous pouvez alors ajouter des lignes
supplémentaires.
-
Pour commencer le test, cliquez avec le bouton droit sur le diagramme dans le navigateur et sélectionnez
Rational Test > Generate Scenario Test (Générer un test de scénario). Si vous êtes invité à vous
connecter à un projet, faites-le.
-
Une boîte de dialogue s'affiche et vous invite à sélectionner les cibles du test de scénario. Sélectionnez tous les
composants du diagramme qui seront utilisés dans le test. Les opérations correspondantes à chaque composant
sélectionné, spécifiées dans le message du composant, seront appelées.
Pour les composants COM
-
Ouvrez la séquence ou le diagramme de collaboration qui modélise le scénario testé. Il est important de spécifier
des messages pour les composants du diagramme qui seront testés. Pour spécifier ces messages, effectuez un
double-clic sur la ligne de message et spécifiez un nom dans la boîte à liste déroulante de l'onglet General
(Général). Ce nom doit correspondre à l'opération testée. Par la suite, ces spécifications peuvent être modifiées
de manière à inclure les données de jeu d'essai.
Par exemple, Rose indiquera par défaut cette spécification de message :
getTransactions(customerID : String)
Cette spécification peut être modifiée comme suit, de manière à inclure un seul cas de donnée :
getTransactions(customerID : String="BBryson")
Pour chaque test de scénario, QualityArchitect génère automatiquement un groupe de données pour les données
de jeu d'essai. Les données du diagramme sont insérées dans la première ligne. Vous pouvez alors ajouter des lignes
supplémentaires.
-
Pour commencer le test, cliquez avec le bouton droit sur le diagramme dans le navigateur et sélectionnez
Rational Test > Generate Scenario Test (Générer un test de scénario). Si vous êtes invité à vous
connecter à un projet, faites-le.
-
Une boîte de dialogue s'affiche et vous invite à sélectionner les cibles du test de scénario. Sélectionnez tous les
composants du diagramme qui seront utilisés dans le test. Les opérations correspondantes à chaque composant
sélectionné, spécifiées dans le message du composant, seront appelées.
Points de vérification
Pour chaque opération appelée, ainsi qu'à la fin du test, vous serez invité à insérer un point de vérification.
QualityArchitect utilise les points de vérification pour confirmer que les opérations se sont effectuées correctement.
Bien que l'architecture des points de vérification soit ouverte et extensible, seul le point de vérification de la base
de données est actuellement implémenté. Ce point de vérification vous permet d'entrer une instruction SQL pour exécuter
une requête. La requête créée sera exécutée au moment du test pour confirmer que la base de données a été correctement
manipulée par le composant.
Vous pouvez implémenter vos propres
points de vérification en suivant les étapes décrites dans l'aide en ligne de QualityArchitect.
-
Sélectionner Oui pour insérer un point de vérification.
-
Sélectionnez le type de point de vérification approprié. A moins que vous n'ayez implémenté vos propres points de
vérification, vous devez sélectionner Database VP (Points de vérification de la base de données).
-
Un générateur de requête apparaît. Vous l'utiliserez pour définir les paramètres de connexion à votre base de
données et générer la requête qui sera exécutée pour valider le bon fonctionnement de l'opération appelée. Pour
établir cette connexion et créer cette requête, il est nécessaire de posséder un minimum de notions concernant la
base de données et la syntaxe SQL sous-jacentes.
Dans cette étape, le code nécessaire à l'instanciation de tous les composants, à l'appel de toutes les opérations et à
l'exécution des points de vérification insérés constitue une sortie.
Génération des données du test de scénario
Pour chaque test de scénario généré, QualityArchitect crée automatiquement un groupe de données pour contenir les
données de test. Si des données ont été spécifiées dans le diagramme, la première ligne du groupe de données contiendra
déjà ces informations, ainsi que les informations liées à tout point de vérification inséré. Sinon, le groupe de
données ne contiendra que les informations liées aux points de vérification.
Pour visualiser et éditer ces informations, suivez ces étapes :
-
Depuis Rose, sélectionnez Tools > Rational Test > Toolbar (Outils > Rational Test > Barre d'outils).
-
Dans la barre d'outils, sélectionnez le deuxième élément, afin d'éditer votre groupe de données. QualityArchitect
aura créé un groupe de données contenant le nom du diagramme de scénario, qui finit par _D. L'algorithme utilisé
pour nommer le groupe de données est tellement complexe qu'il est trop difficile de prévoir chaque nom de groupe de
données dans cette documentation.
Pour éditer ces données, suivez les étapes principales indiquées dans la section Utilisation des groupes de données.
Exécution du test et examen des résultats
Après avoir créé le code et les données du test, vous êtes prêts à exécuter ce dernier. Vous pouvez l'exécuter depuis
l'IDE ou le planifier dans une suite TestManager. Voir Guide d'utilisation de l'outil : Exécution d'une suite de tests à l'aide
de Rational TestManager pour plus d'informations à ce sujet.
-
Au début de l'exécution du test, vous êtes invité à choisir un emplacement pour journaliser les résultats. Une fois
que vous avez spécifié un emplacement, TestManager y consigne les résultats de l'exécution du test.
-
Au terme de l'exécution, TestManager affiche le journal de test. Pour visualiser les résultats de votre test,
sélectionnez l'onglet Detailed View (Vue détaillée) de la fenêtre Log Viewer (Afficheur de journal).
Développez l'arborescence des résultats pour voir les détails de l'exécution du test. Pour obtenir plus
d'informations, cliquez avec le bouton droit sur une ligne quelconque et sélectionnez Properties
(Propriétés).
En ce qui concerne les points de vérification, aucune indication Pass ou Fail (Réussite ou échec) n'est
donnée lors de la première exécution. En effet, cette dernière sert à obtenir une photographie instantanée des
résultats de la requête, qui seront utilisés comme données de référence pour les exécutions suivantes.
Effectuez un double-clic sur les points de vérification pour afficher un comparateur qui présente les résultats de la
requête. Ces résultats peuvent être édités, de sorte que si la requête n'a pas renvoyé les bons résultats, vous pouvez
les modifier. Toutes les exécutions suivantes compareront les résultats de leur requête à ceux qui ont été enregistrés
lors de la première exécution du test.
Les composants testés lors d'un test d'unité ou de scénario s'appuient souvent sur d'autres composants pour achever
leurs tâches. Les problèmes surviennent lorsque ces composants secondaires ne sont pas opérationnels. Parfois, ils sont
encore en développement ; parfois, ils possèdent des bogues. Pour autant, le test du composant primaire ne doit pas
être suspendu jusqu'à ce que les composants secondaires soient disponibles. Pour y remédier, un composant temporaire ou
module de remplacement peut substituer tout composant non opérationnel à des fins de test. Le module de remplacement
n'implémente pas la fonctionnalité du composant réel ; il se contente de réagir aux entrées. Les modules de
remplacement renvoient une réponse programmée pour un certain ensemble de valeurs sans implémenter de logique. C'est
une simple relation stimulus-réaction.
QualityArchitect peut aisément créer des modules de remplacement pour les composants COM et EJB. Ces modules s'appuient
sur des tables de consultation pour répliquer la logique métier des composants qu'ils remplacent. Ces tables,
implémentées en tant que groupes de données, déterminent la valeur que devrait renvoyer un certain ensemble d'entrées.
Le processus de création et de déploiement d'un module de remplacement comprend ces trois étapes :
-
Génération d'un module de remplacement
-
Génération d'une table de consultation pour le module de remplacement
-
Déploiement du module de remplacement
Génération d'un module de remplacement
Lorsque vous générez un module de remplacement, celui-ci doit être complet. Pour les opérations qui l'utilisent, vous
devez créer une table de consultation. Le processus de génération du module de remplacement aboutit à la création d'un
module qui contient le code de toutes ses opérations. Vous ne pouvez créer de module de remplacement pour une seule
opération.
Pour les composants Com
-
Sélectionnez l'interface du composant dans la vue logique.
-
Cliquez avec le bouton droit sur cette interface et sélectionnez Rational Test > Generate Stub (Générer
un module de remplacement). Vous êtes invité à choisir l'emplacement du code du module de remplacement généré.
Sélectionnez cet emplacement et le code sera généré.
Pour les composants EJB
-
Sélectionnez la classe d'implémentation du bean dans la vue logique.
-
Cliquez avec le bouton droit sur cette classe et sélectionnez Rational Test > Generate Stub (Générer un
module de remplacement). Vous êtes invité à choisir l'emplacement du code du module de remplacement généré.
Sélectionnez cet emplacement et le code sera généré.
Génération d'une table de consultation pour le module de remplacement
Pour répliquer la logique du composant réel, le module de remplacement doit savoir quelle est la réaction de ce
composant lorsqu'on lui applique un certain ensemble d'arguments. Cette logique est maintenue dans une table de
consultation, qui indique la valeur ou l'erreur à renvoyer pour un certain ensemble d'arguments. Créez une table de
consultation pour chaque opération effectuée sur le composant.
Pour les composants Com
-
Sélectionnez l'opération sous l'interface du composant dans la vue logique.
-
Cliquez avec le bouton droit sur l'interface et sélectionnez Rational Test > Create Lookup Table (Créer
une table de consultation). La boîte de dialogue Datapool Properties (Propriétés du groupe de données) s'affiche.
-
Pour créer cette table de consultation, suivez les étapes principales indiquées dans la section Utilisation des groupes de données. Vous utiliserez cette table pour y
spécifier les valeurs ou exceptions à renvoyer pour un certain ensemble d'arguments.
Pour les composants EJB
-
Sélectionnez l'opération en-dehors de la classe d'implémentation du bean dans la vue logique.
-
Cliquez avec le bouton droit sur la classe et sélectionnez
-
Rational Test > Create Lookup Table (Créer une table de consultation). La boîte de dialogue Datapool
Properties (Propriétés du groupe de données) s'affiche.
-
Pour créer cette table de consultation, suivez les étapes principales indiquées dans la section Utilisation des groupes de données. Vous utiliserez cette table pour y
spécifier les valeurs ou exceptions à renvoyer pour un certain ensemble d'arguments.
Déploiement du module de remplacement
Après génération du module de remplacement et de la table de consultation, le module doit être déployé à la place du
composant existant. Ce processus est spécifique à l'environnement ; vous trouverez des conseils relatifs à cette tâche
sous le titre de l'aide en ligne de QualityArchitect.
L'enregistreur de session EJB est une application Java qui vous permet d'interagir en direct avec des composants EJB
déployés. Cette fonctionnalité n'est disponible que pour Enterprise JavaBeans, et non pour les composants COM.
Le processus d'utilisation de l'enregistreur de session EJB comprend les étapes suivantes :
-
Démarrage d'une session d'enregistrement XML
-
Connexion au serveur EJB
-
Création d'une instance du bean testé
-
Appel d'une opération sur le bean
-
Insertion de points de vérification et d'un code Java
-
Génération du code de test depuis l'enregistrement de session EJB
L'enregistreur de session EJB possède deux modes d'utilisation : enregistrement et non-enregistrement. Lorsque
l'enregistreur de session EJB est en mode enregistrement, toutes les actions appliquées sont enregistrées dans un
journal XML qu'il convertira en code Java exécutable. Ce code contient tous les appels de méthode, tout code Java
inséré, ainsi que les points de vérification. En mode non-enregistrement, l'outil se limite à créer des instances d'EJB
et à appeler leurs opérations.
-
Pour vous connecter au serveur EJB, vous devez indiquer l'adresse URL du fournisseur et l'InitialContextFactory.
Ces informations devraient correspondre à celles qu'utilise votre code client pour se connecter au serveur. Les
informations de connexion par défaut de WebSphere et de Web Logic se trouvent sur la documentation en ligne du
produit.
-
Après avoir entré vos informations de connexion, sélectionnez Connect (Se connecter) et une liste de beans
déployés sur ce serveur apparaît. Vous pouvez interagir avec un à plusieurs beans au cours d'une session.
Sélectionnez le premier bean avec lequel vous souhaitez interagir.
-
Cette étape permet de créer une instance du premier bean testé. Sélectionnez la méthode de création appropriée dans
la moitié supérieure de la fenêtre des méthodes. Si la méthode de création nécessite des paramètres particuliers,
spécifiez-les dans la section Parameters (Paramètres). Après quoi, sélectionnez Invoke (Appeler) pour
créer une instance du bean.
-
Lorsque l'instance du bean a été créée, l'enregistreur de session EJB vous présente les différentes opérations
disponibles sur ce bean. Vous verrez les opérations du bean dans la moitié supérieure de la fenêtre des méthodes,
et les opérations héritées dans la moitié inférieure. En règle générale, vous ne testerez pas les opérations
héritées. Après avoir sélectionné l'opération à tester, vous pouvez spécifier les paramètres requis pour cette
opération dans la fenêtre des paramètres.
-
Si le paramètre est un objet complexe, un bouton intitulé New (Nouveau) apparaît. Il ouvre une fenêtre dans
laquelle une boîte de dialogue vous permet de créer une instance de l'objet requis. Cette fenêtre affiche tous les
constructeurs et les arguments requis pour construire une instance de l'objet. Après avoir entré les informations
relatives aux constructeurs, vous devez nommer l'objet pour pouvoir le référencer par la suite, si nécessaire, au
cours de l'enregistrement.
-
Il est intéressant d'attribuer des noms aux paramètres si ces valeurs seront réutilisées lors de l'enregistrement
de la session. Si vous indiquez un nom, QualityArchitect pourra insérer cette valeur dans toute zone de paramètres
sur laquelle vous cliquerez avec le bouton droit.
-
Lorsque vous cliquez sur Invoke (Appeler), l'opération est appelée avec les paramètres fournis. La valeur de
retour est indiquée dans la zone Last Return Value (Dernière valeur de retour). Si cette valeur est requise
en tant qu'entrée pour un appel suivant, vous pouvez la glisser-déposer dans la zone requise. Vous pouvez également
effectuer un clic droit lorsque la souris se trouve sur la zone de paramètres dans laquelle la valeur sera insérée.
Pour déterminer les valeurs à présenter dans le menu contextuel, l'enregistreur de session EJB fait correspondre le
type de paramètre aux types précédemment utilisés lors du test.
-
A tout moment dans la session, vous pouvez insérer un code Java ou des points de vérification depuis le menu
Insert (Insérer). Les points de vérification correspondent à ceux qui ont été utilisés lors de la génération
du code du test de scénario. De la même manière, vous pouvez insérer un code Java pour effectuer des traitements
supplémentaires.
-
Si vous êtes en mode enregistrement, vous pouvez convertir l'enregistrement XML en code Java lorsque toutes les
étapes de votre test ont été effectuées. Pour ce faire, cliquez sur Stop (Arrêter). Vous êtes invité à
convertir le code XML en code Java et vous devez indiquer un nom de session et un nom de script. Le code Java, que
vous pouvez exécuter pour répéter les étapes enregistrées, constitue la sortie de ce processus.
|