Flex et le mystère Mustella
Cela fait plusieurs fois que ce nom est mentionné dans les notes de version Apache Flex. Dans la toute récente version 4.9.0, une fois encore, il était question de : « The “Mustella” testing framework has been improved and many tests have been updated. ». Notez les guillemets entourant le nom du projet qui trahissent, sans doute, la part de mystère qui entoure ce projet.
Pour avoir tenté, à plusieurs reprises et en vain, d’insérer, dans l’intégration continue, des tests automatisés d’IHM sur des projets Flex avec FlexMonkey, FlexMonkium…, je suis devenu un peu sceptique sur ce type de frameworks. Pas tant au niveau de leur intérêt mais plutôt au niveau de l’usage et de leur rentabilité. Autant, les tests FlexUnit fonctionnent en standalone, sont efficaces, et restent acceptables sur le plan du maintien des jeux de tests.
Autant les outils de tests IHM sont souvent des usines à gaz qui nécessitent beaucoup d’intégration avec d’autres outils et les jeux de tests sont très couteux à maintenir. Ceci dit, je n’ai toujours pas renoncé, et l’annonce de ce nouveau framework a attiré mon attention. J’ai donc creusé un peu histoire de découvrir ce nouveau venu.
Mais qu’est-ce donc que ce « Mustella »
Non, il ne s’agit pas d’un produit chocolaté à l’huile de palme, ni d’un produit pour bébé… Il semble que les informaticiens ne soient pas au fait des noms de marques de produits pour bébé ?! Ce qui pose problème quand ils nomment des projets : Les informations sur ce framework ne sont pas légions mais avec un nom aussi proche d’une grande marque de produit de premier âge, il devient vraiment difficile de s’y retrouver parmi les résultats des moteurs de recherche.
Plus sérieusement, Mustella était un projet interne chez Adobe utilisé pour automatiser des tests fonctionnels. Il passe petit à petit sous le giron d’Apache. Autant le dire tout de suite, bien que Apachizé, fonctionnel et maintenu, il n’est toujours pas prêt pour une intégration dans vos chaines de production logicielles favorites. Son code est intimement lié à l’arborescence des sources du SDK Flex.
Mustella est un framework développé en Flex (à 98%) et quelques classes java. Il se propose de faire des tests fonctionnels et graphiques. Il se positionne donc comme complément des tests unitaires plus classiques déjà adressés par FlexUnit. Le principal usage qui en est fait actuellement est la validation de comportements visuels de composants graphiques. Il est aujourd’hui utilisé par les développeurs Apache pour tester la majeure partie des composants graphiques du framework Flex.
Concrètement, pour lancer un test avec Mustella il vous faut (en plus de Mustella) :
- Des classes de tests
- Les sources et ressources de l’application à tester
Rien de plus que pour des TU finalement… Là normalement, vous vous dites : Comment fait-il pour les tests graphiques ? Ne manque-t-il pas tout un référentiel de copies d’écran faite à l’arrache avec l’Impr Ecr et Paint sur l’application en prod ? Et bien non, Mustella se propose de les gérer pour vous : Un vrai plus, quand on sait le travail que cela représente ! Lors du premier lancement, l’option -createImages va créer automatiquement les images afin de les archiver et de s’en servir comme référence pour les lancements suivants (sans l’option). Voici un exemple de test :
<?xml version="1.0" encoding="utf-8"?>
<UnitTester testDir="./" xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns="*" testSWF="MustellaHelloWord.mxml">
<mx:Script>
<![CDATA[
import mx.collections.ArrayCollection;
import com.zenika.mustellaHelloword.model.Consultant;
[Bindable]
private static var consultants:ArrayCollection = new ArrayCollection([new Consultant("Martin","Mouterde","zenika.png")]);
]]>
</mx:Script>
<setup>
<ResetComponent target="consultantsGrid" className="spark.component.DataGrid" waitEvent="updateComplete" waitTarget="consultantsGrid"/>
</setup>
<testCases>
<TestCase testID="logoInGrid">
<body>
<SetProperty propertyName="consultants" value="{consultants}" target="consultantsGrid" />
<AssertPropertyValue propertyName="dataProviderLength" value="1" target="consultantsGrid"/>
<CompareBitmap url="./baselines/logoInGrid.png" target="consultantsGrid"/>
</body>
</TestCase>
</testCases>
</UnitTester>
Un des reproches qu’on pouvait faire au duo FlexMonkey/Selenium c’est que dans la logique d’un framework à composant comme Flex, il est incontournable d’avoir sur un même écran plusieurs instances d’un même composant. Mustella ne réinvente rien à ce sujet,
il sera lui aussi perdu sur un test à l’échelle de l’application, mais son usage est différent : Il teste le composant de manière isolée (bouchonnée si besoin par le code de test). Et pour cela pas besoin de gérer / déployer de petites sous applications. Il automatise, en quelque sorte, la compilation, le lancement, le test de multiples applications Flex Standalone ne comportant qu’un composant animé par du code de test.
Et même les différents navigateurs ou plateformes :
Mustella, par défaut utilise le FlexPlayerDebugger standalone. Mais il est possible, et c’est utilisé aussi comme cela par les développeurs Flex, de préciser un navigateur ou une plateforme d’exécution y compris des plateformes mobiles (iOs, Android…). Pour conclure sur ce premier portrait, Mustella n’est pas encore prêt à un usage déconnecté des sources du SDK Flex, dans les outils d’intégration continue, mais il constitue déjà un outil plutôt abouti de tests fonctionnels. Espérons qu’il sorte rapidement de son enclave pour que tous les projets Flex puissent en profiter.
Je connais des frameworks IHM comme Selenium pour Java, mais je n’arrive pas à comprendre l’utilité du référentiel de copies d’écran que tu mentionnes. Peux-tu en dire plus?
Merci pour l’info sur Mustella. Vous avez essayé Sikuli ( http://www.sikuli.org/ ) ?
Article intéressant. Merci !
@Fabian : Certains outils, comme Selenium, testent les IHM « de l’intérieur » avec des id dans le code, pour ceux là, effectivement, il n’y a pas besoin de copies d’écran. En revanche, pour d’autres comme Sikuli, iTestBot ou en l’occurrence Mustella, les tests sont validés ou non par comparaisons d’images d’où la nécessité d’un référentiel d’image.
@Jean Paliès : Sikuli est un très bon outil de tests graphiques qui propose des outils de création des jeux de tests de plus en plus performant. Néanmoins, la stratégie de Mustella qui permet des tests composant par composant à la manière des tests unitaires et qui fournit un outil pour régénérer les captures d’écran me parait prometteuse.
Merci pour l’information! Avec un tel référentiel, la maintenance me semble un peu compliquée, j’imagine qu’il faut mettre à jour les copies d’écran suite à une modification des données de tests pour que les tests IHM repassent à nouveau.
Globalement que ce soit dans le code ou par des images, les tests IHM sont et seront sans doute toujours difficiles à maintenir… Je les préconise pour les applications et fonctionnalités à haut risque (dans le sens perte d’argent ou autre)!