Visual Studio 2010 – Quoi de neuf ? Les tests d’interfaces graphiques !

Nous allons maintenant parler d’une nouveauté très attendue de l’édition Team Test de Visual Studio 2010 : les Tests d’interfaces graphiques. J’en avais déjà parlé dans un précédent article basé à l’époque sur la version Community Technology Preview d’octobre 2008. La version disponible dans la beta 1 à été revue, notamment au niveau du design des outils. Nous allons également découvrir une fonctionnalité très intéressante : la possibilité de créer un test automatisé d’interface graphique à partir d’un enregistrement effectué à partir de l’outil Microsoft Test and Lab Manager.

Le principe

Tester l’aspect fonctionnel d’une interface graphique peut rapidement devenir redondant et prend énormément de temps aux équipes de test. Même s’il faut toujours une validation humaine pour certains tests, la majorité de ce type de scénarios peut être automatisé sans trop de problèmes. C’est le rôle de ce nouveau type de test : les tests d’interfaces graphiques ou Coded Ui Tests.

Qu’est-ce qu’un coded ui test ?

Il s’agit d’une méthode de test, ressemblant fortement aux tests unitaires, contenant du code qui permet de simuler des actions normalement effectuées par un utilisateur. Bien évidemment, on ne va pas écrire nous même ce code : il sera généré par un enregistreur. L’idée est d’effectuer une première fois manuellement le scénario pendant qu’un outil analyse ce qui se passe et produit un ensemble de méthodes que nous pourrons alors appeler pour rejouer ce scénario.

Jouer un test seul n’a pas de grande utilité. Il trouve son réel intérêt lorsqu’on y ajoute de la validation, ce qui est tout à fait possible grâce à un second outil qui permet de sélectionner les contrôles d’une application pour pouvoir en vérifier la valeur lors du test.

La nouvelle interface d’enregistrement

Pour commencer, il vous faut un projet de type test que vous rajoutez à une solution existante (ou une nouvelle solution):

image

nb : on admirera au passage la nouvelle interface d’ajout de projet :)

Une fois le test ajouté, il suffit de créer un test de type Coded Ui Test:

image

On nous propose alors de choisir le type d’outil que l’on souhaite utiliser :

image

(Notez que le texte d’aide est un peu plus explicite que dans la version précédente.)

Il existe 3 outils :

  • Un assistant de création de test d’interface à partir d’un enregistrement pré fait (dont nous parlerons plus loin)
  • L’enregistreur d’actions
  • Le sélectionneur de contrôle, qui permet d’ajouter des contrôles à valider dans un test

L’utilisation la plus courante sera le second outil: le Test Builder :

image

Revu par rapport à la précédente version, il est simplifié et plus clair. On remarquera également qu’il y a maintenant deux onglets, le premier concernant l’enregistrement des actions, le second l’ajout de validation pour le test.

Après avoir cliqué sur Record Actions, l’outil d’enregistrement d’actions trace tout ce que nous faisons. Une fois une étape du test terminée, on renseigne le nom de la méthode qui permettra de rejouer cette étape, et on clique sur Generate Method :

nb : une “étape” peut bien entendu comprendre plusieurs actions, la capture ci-dessous n’étant qu’un exemple

image

Plutôt simple, non ? :)

Je vous conseille vivement de découper un scénario en plusieurs méthodes pour pouvoir facilement les réutiliser dans d’autres tests et ne pas avoir à ré enregistrer chaque fois des actions comme : “ouverture de l’application”, “connexion en tant qu’administrateur”, etc.

Chaque fois que vous générez méthode, vous revenez à l’interface principale, qui vous permet de savoir où vous en êtes dans votre scénario :

image

Passons maintenant à l’ajout de validation, pour cela, l’onglet Add Assertions est là !

image

Après avoir cliqué sur le bouton ci-dessus, nous avons accès à l’outil de sélection de contrôle. Pour choisir un contrôle d’une application, il suffit de glisser/déposer la cible que l’on voit en haut à droite sur le contrôle en question.

image

Il ne reste plus qu’a ajouter le contrôle à la liste de ceux que l’on veut valider, et cliquer sur Show Properties pour afficher la liste de ses propriétés publiques. Elle sont automatiquement découvertes par l’outil qui nous invite à en sélectionner une ou plusieurs, et à choisir comment et à quelle valeur il faudra la comparer pendant l’exécution automatique du test :

image

Après avoir ajouté tous les contrôles que vous souhaitez valider, fermez l’outil principal (on vous demande alors si vous voulez générer le code, répondez oui bien entendu).

Le code généré

Je ne vais pas revenir en détail sur le code qui est généré, mais on retrouve 6 fichiers :

  • App.config
  • NomDuTest.cs : contient le test, les appels aux méthodes de simulation et la validation
  • RecordedMethods.cs : contient les méthode de simulation
  • UIMap.uitest associé à UIMap.designer.cs : Contient des informations nécessaires à la localisation des contrôles
  • UserControl.cs : contient le code wrappant les appels aux controles windows. Utilisé dans RecordedMethods.cs

Plus particulièrement, voici le code du test que j’ai généré plus haut :

image

Si vous créez un test automatisé ressemblant à celui-ci, vous remarquerez que je l’ai légèrement modifié comme indiqué dans les commentaires pour sauvegarder la valeur à valider avant la fermeture de l’application.

L’exécution peut être faite directement via le menu contextuel dans le code :

image

image

De plus, on peut très facilement enregistrer des actions supplémentaires ou ajouter de la validation par après, toujours via le menu contextuel :

image

Exploiter une automatisation déjà enregistrée

Nous avons vu dans le billet sur Microsoft Test and Lab Manager qu’il est possible d’enregistrer les actions réalisées pendant le test manuel. Vous comprenez maintenant à quoi correspondait alors le fichier .uitest généré. Nous allons maintenant voir un exemple de l’interaction que l’on peut avoir entre les différents outils.

L’idée est très astucieuse et par du principe qu’un testeur ne doit pas perdre de temps à effectuer des actions répétitives. Pourquoi serait-il forcé de toujours rejouer les mêmes tests ?

Le scénario est le suivant :

  • Le testeur joue manuellement un cas de test via Microsoft Test and Lab Manager
  • Après la réalisation du test, un fichier contenant les actions qu’il a réalisé est sauvegardé dans le work item
  • Un testeur technique créé alors un test d’interface graphique automatisé
  • Ce test peut rejoindre la batterie de tests automatiques jouée lors des tests d’intégration
  • Tant qu’il n’est pas nécessaire de rejouer manuellement le test, l’équipe de test peut se concentrer sur d’autres scénarios

Le gain de temps est au rendez-vous, difficile de ne pas adhérer au principe ! :)

Pour cela, nous allons choisir la première option lors de la création d’un test d’interface graphique :

image

On nous invite à sélectionner un work item de type Test Case :

image

On clique sur OK et le test est généré.

nb: lorsque vous créez un test d’interface graphique dans un projet qui en contient déjà un, seul le fichier contenant le test est ajouté, les méthodes sont toutes centralisées dans le même fichier RecordedMethods.cs.

Le code généré est relativement clair, puisqu’il reprend les étapes du Test Case :

image

Tout ce qu’il reste à faire, c’est d’ajouter la validation comme vu plus haut !

Conclusion

Bien qu’étant plutôt à classer dans la catégorie des tests techniques, les tests d’interfaces graphiques permettent de compléter le travail des testeurs génériques et fonctionnels. Automatiser un grand nombre de scénarios permettra d’ajouter à la qualité de chaque build d’intégration et laissera le soin aux équipes de test de se concentrer sur les fonctionnalités les plus critiques et complexes.

Voilà encore une fonctionnalité très aboutie de cette version 2010 de Visual Studio :)

Bon tests !

.Dispose();

Publié mercredi 20 mai 2009 09:00 par Etienne Margraff
Classé sous ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires


Les 10 derniers blogs postés

- Emportez votre sélection de la MSDN dans la poche ? par Blog de Jérémy Jeanson le 04-17-2014, 22:24

- [ #Office365 ] Pb de connexion du flux Yammer ajouté à un site SharePoint par Le blog de Patrick [MVP SharePoint] le 04-17-2014, 17:03

- NFluent & Data Annotations : coder ses propres assertions par Fathi Bellahcene le 04-17-2014, 16:54

- Installer un site ASP.net 32bits sur un serveur exécutant SharePoint 2013 par Blog de Jérémy Jeanson le 04-17-2014, 06:34

- [ SharePoint Summit 2014 ] Tests de montée en charge SharePoint par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 20:44

- [ SharePoint Summit 2014 ] Bâtir un site web public avec Office 365 par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 18:30

- Kinect + Speech Recognition + Eedomus = Dommy par Aurélien GALTIER le 04-16-2014, 17:17

- [ SharePoint Summit 2014 ] Une méthodologie simple pour concevoir vos applications OOTB SharePoint de A à Z par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 16:51

- //Lean/ - Apprendre à faire des Apps Windows universelles par Blog de Jérémy Jeanson le 04-16-2014, 12:57

- Une culture de la donnée pour tous… par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 11:00