Meilleures pratiques pour les tests codés de l'interface utilisateur

Article
08/10/2011

Cette rubrique décrit les meilleures pratiques pour le développement de tests codés de l'interface utilisateur.

Meilleures pratiques

Utilisez les instructions suivantes pour créer un test codé de l'interface utilisateur flexible.

Utilisez le Générateur de test codé de l'interface utilisateur à chaque fois que possible.
Ne modifiez pas le fichier UIMap.designer.cs directement. Sinon, les modifications apportées au fichier seront remplacées.
Créez votre test comme une séquence de méthodes enregistrées. Pour plus d'informations sur l'enregistrement d'un méthode, consultez Comment : créer un test codé de l'interface utilisateur.
Chaque méthode enregistrée doit agir dans une page, un formulaire ou une boîte de dialogue unique. Créez une méthode de test pour chaque nouvelle page, formulaire ou boîte de dialogue.
Lorsque vous créez une méthode, utilisez un nom de méthode explicite plutôt que le nom par défaut. Un nom explicite permet d'identifier l'objectif de la méthode.
Lorsque cela s'avère possible, limitez chaque méthode enregistrée à un nombre d'actions inférieur à 10. Cette approche modulaire simplifie le remplacement d'une méthode si l'interface utilisateur change.
Créez chaque assertion à l'aide du Générateur de test codé de l'interface utilisateur, qui ajoute automatiquement une méthode d'assertion au fichier UIMap.Designer.cs.
Si l'interface utilisateur (IU) change, ré-enregistrez les méthodes de test, ou les méthodes d'assertion, ou ré-enregistrez les sections affectées d'une méthode de test existante.
Créez un fichier UIMap séparé pour chaque module dans votre application testée. Pour plus d'informations, consultez Test d'une grande application avec plusieurs mappages d'IU.
Dans l'application testée, utilisez des noms explicites lorsque vous créez des contrôles IU. Ils sont plus significatifs et donc plus faciles d'utilisation que les noms de contrôle générés automatiquement.
Si vous créez des assertions en codant avec l'API, créez une méthode pour chaque assertion dans la partie de la classe UIMap qui se trouve dans le fichier UIMap.cs. Appelez cette méthode de votre méthode de test pour exécuter l'assertion.
Si vous codez directement avec l'API, utilisez les propriétés et les méthodes dans les classes générées dans le fichier UIMap.Designer.cs dans votre code autant que possible. Ces classes permettent de rendre votre travail, plus facile, plus fiable et plus productif.

Les tests codés de l'interface utilisateur s'adaptent automatiquement à de nombreuses modifications de l'interface utilisateur. Si, par exemple, la position ou la couleur d'un élément d'interface a été modifiée, la plupart du temps le test codé de l'interface utilisateur sera toujours en mesure de trouver l'élément correct.

Pendant l'exécution d'un test, les contrôles UI sont identifiés par l'infrastructure de test à l'aide d'un ensemble des propriétés de recherche appliquées à chaque classe de contrôle dans les définitions créées par le Générateur de test codé de l'interface utilisateur dans le fichier UIMap.Designer.cs. Les propriétés de recherche contiennent les paires nom-valeur des noms de propriété et des valeurs de propriété qui peuvent être utilisés pour identifier le contrôle, tel que les propriétés FriendlyName, Nameet ControlType du contrôle. Si les propriétés de recherche restent inchangées, le test codé de l'interface utilisateur sera en mesure de trouver le contrôle dans l'IU. Si les propriétés de recherche sont modifiées, les tests codés de l'interface utilisateur ont un algorithme de correspondance intelligent qui applique des méthodes heuristiques pour trouver des contrôles et des fenêtres dans l'IU. Lorsque l'IU a changé, vous pouvez être en mesure de modifier les propriétés de recherche des éléments identifiés précédemment pour vous assurer qu'ils sont trouvés.

Que faire si votre interface utilisateur change ?

Les interfaces utilisateur changent fréquemment pendant le développement. Voici certains moyens d'atténuer l'effet de ces modifications :

Recherchez la méthode enregistrée qui référence ce contrôle et utilisez le Générateur de test codé de l'interface utilisateur pour réenregistrer les actions de cette méthode. Vous pouvez utiliser le même nom de la méthode pour remplacer les actions existantes.
Si l'assertion d'un contrôle n'est plus valide :
- Supprimez la méthode qui contient l'assertion.
- Supprimez l'appel à cette méthode depuis la méthode de test.
- Ajoutez une nouvelle assertion en faisant glisser le bouton de croix sur le contrôle d'interface utilisateur, ouvrez le plan d'interface utilisateur et ajoutez la nouvelle assertion.

Pour plus d'informations sur l'enregistrement de tests codés de l'interface utilisateur, consultez Comment : générer un test codé de l'interface utilisateur en enregistrant l'application testée ou Comment : créer un test codé de l'interface utilisateur.

Que faire si un processus d'arrière-plan doit se terminer avant que le test ne puisse continuer

Vous devrez peut-être attendre la fin d'un processus avant de pouvoir continuer avec l'action d'interface utilisateur suivante. Pour ce faire, vous pouvez utiliser WaitForReadyLevel pour attendre avant que le test ne continue comme dans l'exemple suivant.

// Set the playback to wait for all threads to finish
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;

// Press the submit button
this.UIMap.ClickSubmit();

// Reset the playback to wait only for the UI thread to finish
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.UIThreadOnly;