Apparus avec la version 2010 de Visual Studio et TFS, les Coded UI Tests représentent l’étape ultime des tests d’un site web. En effet, ils sont le complément des tests unitaires, tests fonctionnels (avec Fitnesse par exemple) et autres tests de charge etc. Ils arrivent à la fin du cycle de développement puisqu’ils servent principalement à la détection des régressions. Dans ce cas ils sont codés lorsque le scénario qu’ils testent est validé fonctionnellement.

Dans cet article, nous allons voir comment écrire (ou plutôt générer) un Coded UI Test. Un second billet détaillera comment les automatiser avec une build TFS.

Le scénario de test

Comme tout test, mais plus encore dans le cas d’un Coded UI Test, le scénario est un élément primordial de réussite. En effet mettre en place ce genre de test peut devenir très lourd à maintenir, je vous conseille donc d’en limiter le nombre, en choisissant des fonctionnalités majeures avec un nombre d’étape réduit. (ex : l’ajout panier d’un site e-commerce)

Si Visual Studio peut être utilisé seul pour créer des Coded UI Test, il est préférable d’utiliser Microsoft Test Manager (disponible avec certaines versions de VS) pour définir un scénario via un Test Case. Ce travail peut ainsi être réaliser par un testeur. Cela permettra aussi de les automatiser.

Il faut pour cela créer un Test Plan au niveau du Team Project.

Puis créer un Test Case en cliquant sur “New” et renseigner les étapes ainsi que le résultat attendu. Pour cela nous restons bien dans la section “Plan” du “Testing Center”.

Il est possible d’ajouter des paramètres à notre test. Ils seront utilisés avec le recorder puis dans le code généré. Attention en procédant ainsi, le paramètre doit être un paramètre d’entrée car le recorder demandera explicitement d’utiliser chaque paramètre. Le test sera joué autant de fois qu’il y a de valeur dans les paramètres.

Le paramètre est alors inséré dans la description de l’étape précédée d’un @.

Et une table apparaît également, permettant de saisir les valeurs du paramètre.

Nous pouvons aussi créer des étapes partagées qu’il est possible de réutiliser d’un test à l’autre. Cette fonctionnalité est aussi accessible via “Organize > Shared Steps Manager”

Enregistrement du test via le recorder

Maintenant que notre scénario de test est défini, nous pouvons l’enregistrer. Cela permettra déjà aux testeurs de gagner du temps puisqu’ils pourront ensuite le relancer manuellement.

Pour cela, nous nous rendons dans la section “Test” puis nous lançons le recorder via un clic droit sur le test case suivi de “Run”. Pour lancer l’enregistrement, “Start Test” en n’oubliant pas de cocher “Create action recording”.

Puis nous déroulons le scénario avec IE en indiquant à chaque fois que l’étape s’est bien déroulée comme attendu (ou pas).

Pour utiliser le paramètre il suffit de cliquer dessus et de le coller dans la textbox qui va bien.

Ensuite lorsque notre test est enregistré il est possible de le rejouer. Pour cela procéder comme précédemment sans cocher “Create action recording”, puis “Play All”.

Tout ce qui a été fait jusqu’ici peut d’ailleurs aussi être utilisé dans le cadre de tests exploratoires. Il est ainsi possible d’ajouter des captures d’écran en cas de bug, ainsi que des annotations. Puis de l’associer à un work item dans TFS.

Créer un Coded UI Test

Notre travail de développeur commence maintenant, et comme tout développeur qui se respecte, nous allons essayer d’écrire le moins de code possible. Comment faire cela ? en générant la plus grande partie du code !

Commençons par créer un nouveau projet dans VS.

Nous choisissons la seconde option, et retrouvons notre test case via son id. Enfin, nous laissons VS générer le code.

Regardons la méthode de test générée. Je passe sur le code généré pour piloter le navigateur et l’UI Map car ils pourraient faire (et peut-être feront) l’objet d’un billet entier.

Nous retrouvons une méthode pour chaque étape du test case.

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.TestCase", "http://gnu-tfs2013.cloudapp.net/tfs/defaultcollection;Demo01", "8", DataAccessMethod.Sequential), TestMethod]
        public void SearchEngineSoftFluent()
        {
            // To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
            this.UIMap.GotoSoftFluentHomePage();
            this.UIMap.TypesearchTermParams.UISearchTextBoxEditText = TestContext.DataRow["Term"].ToString();
            this.UIMap.TypesearchTerm();
            this.UIMap.Cliconsearchbutton();
        }

Comme il y avait un paramètre à notre test nous retrouvons l’attribut datasource sur notre méthode. Les infos à ce sujet : http://msdn.microsoft.com/en-us/library/ee624082.aspx . La chaine de connexion est composée de l’url de la collection de projet, puis “;NomDuTeamProject” puis “IdDuTestCase”. Le paramètre est bien utilisé dans le code via le TestContext.

Mais ne manque-t-il rien à notre test ? La (ou les) assertion (s) bien sûr ! Nous allons donc en ajouter une qui vérifiera le nombre de résultats.

Puis sur notre page de résultats de recherche, nous sélectionnons à l’aide du recorder la zone de la page qui atteste que notre test a réussi.

Comme cette assertion dépend du critère de recherche, nous pouvons (et devons) utiliser un paramètre que l’on ajoute au test case et que nous récupérons dans le code. 

this.UIMap.AssertSearchResultsExpectedValues.UIC002_ctl00_ctl00_resCustomInnerText = TestContext.DataRow["Count"].ToString();
this.UIMap.AssertSearchResults();

Et voilà, nous pouvons maintenant exécuter le test comme un test classique dans Visual Studio.

Pour aller plus loin

Il est possible de générer un rapport détaillé de l’exécution du test en modifiant le fichier de configuration du QTAgent32. exe : http://msdn.microsoft.com/en-us/library/jj159363.aspx

Il est possible de rejouer les tests sur Firefox et Chrome : http://msdn.microsoft.com/en-us/library/jj835758.aspx l’avantage est qu’ils s’exécutent plus rapidement sur Chrome.

Nous avons vu comment créer un Test Case, enregistrer le test, générer le Coded UI Test et utiliser la source de données venant du Work Item. Dans un prochain billet nous verrons comment utiliser TFS pour automatiser l’exécution de ces tests.