Disponible dans sa version 1.0 depuis mi-juillet, FlexMonkey est un framework de test d’interfaces destiné aux applications Flex et AIR.
FlexMonkey permet d’enregistrer et de rejouer les interactions de l’utilisateur avec les composants visuels d’une application ainsi que de vérifier leur comportement.
Nous nous sommes penchés sur cet outil afin de déterminer :
- Quelle place il peut avoir dans le processus de réalisation de nos applications client
- Comment il peut améliorer la qualité finale de nos produits
Découvrez immédiatement le bilan de notre test !
Installation
Il s’agit une étape relativement simple puisqu’elle ne nécessite que le téléchargement et l’installation du lecteur/enregistreur (une application AIR).
Aussi, il est important de noter qu’il n’existe aucune dépendance entre le code de l’application et FlexMonkey, la communication entre le lecteur et l’application se faisant par LocalConnection.
Enregistrement d’un Scénario
Si l’application est destinée à être chargée uniquement dans le navigateur, il est nécessaire d’ajouter un swf spécifique, appelé MonkeyAgent dans le même répertoire que l’application.
Cet agent s’assure de la communication bidirectionnelle entre l’enregistreur et l’application à tester et évite ainsi de devoir écrire du code spécifique à FlexMonkey.
L’enregistrement débute à partir du moment où l’on appuie sur le bouton « Record » de l’enregistreur. À noter qu’il est possible d’organiser ses tests en Test Case et Test Suite.
Capture d’écran de l’application FlexMonkey (AIR App) :
Créer une Application Testable
Les interactions entre la souris/le clavier et les éléments de l’interface sont récupérés par FlexMonkey grâce au FlexAutomationAPI inclus dans le SDK Flex.
Pour plus de détail concernant cette API ainsi que son utilisation, on peut se référer au document suivant : Adobe Flex 2 – Using the Automated Testing API.
La principale contrainte pour créer une application « test friendly » est d’identifier chaque composant de manière unique. En effet, pour pouvoir rejouer les interactions, FlexMonkey requiert un identifiant unique (une chaine de caractères) pour chacun des composants. Cet identifiant est choisi parmi les propriétés suivantes :
- automationName
- id
- automationID
FlexMonkey vérifie d’abord que l’automationName est spécifié. Si cette propriété est renseignée, alors sa valeur devient l’identifiant unique pour les tests.
Dans le cas contraire, il s’agira de la valeur de la propriété id, ou sinon celle de l’automationID, si aucun id n’a été renseigné.
A noter que la valeur de l’automationID est construite automatiquement au runtime et se base sur la place du composant dans la hiérarchie de la DisplayList. Elle ressemble à une chaîne de ce type :
automationClassName{FlexApplication string}
id{MonkeyAgent string}
automationIndex{index:-1 string}
label{ string}
automationName{MonkeyAgent string}
className{MonkeyAgent string}
|
id{null object}
automationIndex{index:0 string}
automationName{index:0 string}
automationClassName{FlexDividedBox string}
label{ string}
className{mx.containers.VDividedBox string}
|
automationClassName{FlexApplication string}
id{null object}
automationIndex{index:1 string}
label{ string}
automationName{file:///C:/Users/Florian/KapIT/Client/Flex.swf string}
className{RPM_Flex string}
|
automationClassName{FlexBox string}
id{mainView string}
automationIndex{index:12 string}
label{ string}
automationName{mainView string}
className{com.client.projet.view.MainView string}
|
automationClassName{FlexBox string}
id{communicationView string}
automationIndex{index:44 string}
label{Communication string}
automationName{Communication string}
className{com.client.projet.view.communication.Communication string}
|
automationClassName{FlexBox string}
id{technicalInterfaceParams string}
automationIndex{index:3 string}
label{ string}
automationName{technicalInterfaceParams string}
className{com.client.projet.view.communication.TechnicalInterfaceParams string}
|
automationClassName{FlexForm string}
id{tInterfaceForm string}
automationIndex{index:3 string}
label{ string}
automationName{tInterfaceForm string}
className{mx.containers.Form string}
|
displayAsPassword{false boolean}
automationName{null:1 string}
automationIndex{index:45 string}
automationClassName{FlexTextArea string}
id{null object}
editable{true boolean}
className{mx.controls.TextInput string}
En plus d’être complètement illisible, ces chaines d’appels ralentiront énormément la lecture des scripts.
Une notion importante à retenir est qu’il est obligatoire que tous les composants testés aient un identifiant unique. 2 mêmes identifiants dans le programme rendront les tests instables à un moment où à un autre. Nous conseillons de se baser sur la propriété automationName car il est fréquent de changer l’id d’un composant durant le développement, ce qui entrainerait alors une modification des scripts de tests.
Vérification des Tests
Lorsqu’une séquence a été enregistrée, il est possible de spécifier quels sont les résultats attendus au niveau de l’interface.
Pour cela, une cible permet de choisir un composant de l’application et de choisir parmi sa liste des propriétés/styles, quelle est la valeur attendue pour une propriété choisie.
Il est dommage que la phase d’introspection semble ralentir l’agent au fur et à mesure de l’enregistrement et de la lecture des scripts. Un redémarrage de l’application devient alors obligatoire. Il s’agit d’un point à améliorer lors des futurs sorties de FlexMonkey.
FlexMonkey dans le Processus d’Intégration Continu
FlexMonkey permet d’exporter les scripts sous forme de classes de tests ActionScript exploitable par FlexUnit 4.
Une tâche ANT spécifique peut-être téléchargé depuis le site de Gorilla Logic et permet d’exécuter les tests lors du build. L’explication détaillée peut être trouvée sur ce même site.
On aurait aimé trouver une solution similaire pour flex-mojos, de la même manière que celle qui existait pour la version 0.8.
À suivre, le retour de cette fonctionnalité dans FlexMonkey.
Conclusion
FlexMonkey semble relativement stable et fonctionnel dans cette version 1.0. S’assurer de la stabilité de l’interface utilisateur en complément des tests unitaires apporte un avantage non négligeable dans le développement d’une application.
À bookmarker :