Dans un article précédant nous avons vu comment créer des Coded UI Tests à partir d’un record provenant d’un Test Case. Nous souhaitons désormais exécuter ces tests automatiquement via TFS par exemple dans le cadre d’un déploiement continu.

Préparation du code

Bien que le code de notre Coded UI Test a été généré via le record d’un Test Case, il faut désormais lier la méthode de test c# à notre Work Item. Pour cela, ouvrons le depuis Visual Studio en ayant la solution de test ouverte puis dans la section “Associated Automotion” sélectionnons notre méthode.

Ajoutons maintenant notre solution au “source control” de façon classique (dans le même Team Project que notre Test Case). Après cela nous allons créer une définition de build qui va simplement compiler cette notre solution. Il s’agit d’une build avec le template par défaut. Il y a 2 petites choses à penser :

– Bien spécifier à répertoire de sortie pour la build (drop folder)

– Dans le process, supprimer l’exécution automatique des tests.

Nous pouvons désormais lancer cette build qui va compiler nos Coded UI Tests. Passons maintenant à l’étape de configuration de l’environnement TFS.

Préparation de l’environnement

Pour pouvoir exécuter des Coded UI Tests, il faut préparer un environnement dans le Lab Center capable de lancer des tests.

La première chose est donc d’installer et de configurer un contrôleur de test dont le fichier d’installation se trouve dans l’iso… de l’agent de test disponible gratuitement dans les logiciels complémentaires sur la page de téléchargement de Visual Studio. L’installation et la configuration (liaison avec TFS, droits etc. ) ne présentent pas de difficulté particulière et sont bien documentées dans la MSDN.

Pensez également que nous aurons besoin d’un poste client (une VM par exemple) pour exécuter les tests.

Ouvrons Test Manager et passons dans le Lab Center :

Nous allons commencer par créer un environnement dans le Lab :

Nous choisissons un environnement standard car nous n’utilisons pas SCVMM.

Ajoutons les machines qui composent cet environnement. Dans notre cas nous n’en avons qu’une, celle qui exécutera les tests. Attention une machine ne peut appartenir qu’à un seul environnement et un environnement est lié à un Team Project.

Nous sommes dans un domaine AD, mais pour un cas comme le nôtre nous pouvons aussi être en workgroup. Attention dans ce cas il faut bien mettre . \ devant le nom d’utilisateur.

Cela n’est néanmoins pas toujours suffisant, dans ce cas vous pouvez essayer ce lien.

Passons ensuite dans la rubrique “Advanced” pour configurer l’environnement pour les tests :

Puis nous cliquons sur “Verify” avant de lancer la création de l’environnement :

Normalement l’agent va être installé et configuré sur chaque machine de l’environnement.

Préparation des paramètres de tests

Nous allons maintenant créer un “Test Settings” pour nos tests automatisés. Pour cela cliquons sur “New” dans la rubrique “Test Settings”.

Il ne faut pas oublier d’indiquer que nos tests sont automatisés :

Au niveau des rôles nous devons indiquer celui de la (ou les machines) qui jouerons les tests, “Desktop Client” dans notre cas. Attention il ne peut qu’un seul rôle qui joue les tests.

Nous pouvons ensuite indiquer par exemple que nous souhaitons enregistrer ce qui se passe sur le poste client afin d’avoir le maximum d’information si le test échoue. Attention cela peut créer un grand nombre de données et vite remplir la base de données. Pensez donc à faire le ménage de temps en temps (avec les power tools par exemple)

Jusque là nous avons donc créé une build qui compile nos tests, un environnement pour les exécuter ainsi que le paramétrage de ces tests. Nous allons maintenant créer la build qui va automatiser l’exécution des tests.

Automatisation des tests

Nous allons créer une nouvelle build définition mais cette fois-ci nous allons utiliser le template du Lab : LabDefaultTemplate11. xaml avec un TFS 2013.

puis éditer la section “Lab Process Settings”.

Nous spécifions alors l’environnement concerné,

puis la build à lancer pour compiler les tests.

Enfin nous indiquons le plan de test et les suites à jouer ainsi que le “test settings”.

Ainsi seront jouer dans ce plan uniquement les test automatisés et sélectionnés dans les suites et dont le code est bien sûr compilé par la première build. Nous pouvons maintenant lancer notre build pour exécuter ces tests, elle devrait passer au vert :)

Un peu long à mettre en place mais ça fonctionne. En cas de problème, pensez à regarder au niveau du firewall de Windows.

Pour aller plus loin

Depuis TFS 2010 nous disposons d’un système intégré pour jouer tout type de tests, mais c’est depuis la version 2012 que cela devient réellement facile à mettre en place. Néanmoins les Coded UI Tests sont lourds à maintenir, et le recording est relativement compliqué à bien prendre en main si l’on veut obtenir un code généré robuste. Vous pouvez alors utiliser la mécanique d’automatisation (décrite dans cette article) et écrire des tests avec Watin ou d’autres frameworks de ce genre. Vous perdrez la génération de code mais vous pourrez alors écrire des tests plus stables et dont vous maitrisez le code. Enfin n’oubliez pas que c’est toujours le scénario qu’il faut bien choisir pour tester des fonctionnalités pertinentes et critiques, et que ces tests ne remplacent ni les tests unitaires, ni les tests fonctionnels du genre Fitnesse et encore moins les tests manuels.