Partager via

Suspension des tests codés de l'interface utilisateur en attendant des événements spécifiques pendant la lecture

  • Article

Dans une lecture du test codé de l'interface utilisateur, vous pouvez indiquer dans le test l'attente de certains événements, par exemple l'affichage d'une fenêtre, la fin de la barre de progression, etc.Pour cela, utilisez la méthode UITestControl.WaitForControlXXX() appropriée, comme décrit dans le tableau suivant.Pour consulter un exemple de test codé de l'interface utilisateur qui illustre l'attente d'un contrôle avant d'être activé à l'aide de la méthode WaitForControlEnabled, consultez Procédures pas à pas : création, édition et gestion d'un test codé de l'interface utilisateur.

Conditions requises

  • Visual Studio Ultimate, Visual Studio Premium
ConseilConseil

Vous pouvez aussi insérer un délai avant l'action d'interface utilisateur à l'aide de l'éditeur de test codé de l'interface utilisateur.Pour plus d'informations, consultez Comment : insérer un délai avant l'action d'interface utilisateur à l'aide de l'éditeur de test codé de l'interface utilisateur.

Méthodes UITestControl.WaitForControlXXX()

Méthodes UITestControl.WaitForControlXXX()

Description

WaitForControlReady

Attend le contrôle pour être prêt à accepter les entrées à la souris et au clavier.Le moteur appelle implicitement cette API pour que toutes les actions attendent le contrôle avant de déclencher une opération.Toutefois, vous devrez peut-être effectuer un appel explicite dans un certain scénario ésotérique.

WaitForControlEnabled

Attend l'activation du contrôle lorsque l'Assistant effectue une validation asynchrone de l'entrée en passant des appels au serveur.Par exemple, la méthode peut attendre l'utilisation du bouton Suivant de l'Assistant avant d'être activée.Pour obtenir un exemple de cette méthode, consultez Procédures pas à pas : création, édition et gestion d'un test codé de l'interface utilisateur.

WaitForControlExist

Attend l'affichage du contrôle sur l'interface utilisateur.Par exemple, vous attendez une boîte de dialogue d'erreur après que l'application a réalisé la validation des paramètres.Le temps nécessaire pour la validation est variable.Vous pouvez utiliser cette méthode pour attendre la boîte de dialogue d'erreur.

WaitForControlNotExist

Attend que le contrôle ne soit plus affiché dans l'interface utilisateur.Par exemple, vous pouvez attendre que la barre de progression disparaisse.

WaitForControlPropertyEqual

Attend que la propriété spécifiée du contrôle a la valeur donnée.Par exemple, vous attendez que le texte d'état devienne Terminé.

WaitForControlPropertyNotEqual

Attend que la propriété spécifiée du contrôle a la valeur opposée à la valeur spécifiée.Par exemple, vous attendez que la zone d'édition ne soit pas en lecture seule, mais modifiable.

WaitForControlCondition

Attend que la valeur retournée du prédicat spécifié soit true.Cela peut être utilisé pour une opération d'attente complexe (comme les conditions OR) sur un contrôle donné.Par exemple, vous pouvez attendre que le texte d'état soit Opération réussie ou Échec comme l'indique le code suivant :

// Define the method to evaluate the condition 
private static bool IsStatusDone(UITestControl control) 
{ 
    WinText statusText = control as WinText; 
    return statusText.DisplayText == "Succeeded" || statusText.DisplayText == "Failed"; 
} 
// In test method, wait till the method evaluates to true 
statusText.WaitForControlCondition(IsStatusDone);

WaitForCondition``1

Toutes les méthodes précédentes sont des méthodes d'instance de UITestControl.Cette méthode est une méthode statique.Cette méthode attend également que la valeur retournée du prédicat spécifié soit true, mais il peut être utilisé pour une opération d'attente complexe (comme les conditions OR) sur plusieurs contrôles.Par exemple, vous pouvez attendre que le texte d'état soit Opération réussie ou qu'un message d'erreur s'affiche, comme l'indique le code suivant :

// Define the method to evaluate the condition 
private static bool IsStatusDoneOrError(UITestControl[] controls) 
{ 
    WinText statusText = controls[0] as WinText; 
    WinWindow errorDialog = controls[1] as WinWindow; 
    return statusText.DisplayText == "Succeeded" || errorDialog.Exists; 
} 
// In test method, wait till the method evaluates to true 
UITestControl.WaitForCondition<UITestControl[]>(new UITestControl[] { statusText, errorDialog }, IsStatusDoneOrError);

Toutes ces méthodes présentent le comportement suivant :

  • Les méthodes retournent la valeur true si l'attente est a abouti et false si l'attente a échoué.

  • Le délai d'attente implicite pour l'opération d'attente est spécifié par la propriété WaitForReadyTimeout.La valeur par défaut de cette propriété est 60 000 millisecondes (une minute).

  • Les méthodes ont une surcharge pour recevoir de délais d'attente explicites en millisecondes.Toutefois, lorsque l'opération d'attente entraîne la recherche implicite du contrôle ou, lorsque l'application est occupée, le temps d'attente réel peut être supérieur au délai d'attente spécifié.

Les fonctions précédentes sont puissantes et flexibles et doivent réunir presque toutes les conditions.Toutefois, si ces méthodes ne répondent pas à vos besoins et que vous devez coder un Wait ou un Sleep dans votre code, il est recommandé d'utiliser la méthode Playback.Wait() au lieu de l'API Thread.Sleep().Les raisons sont les suivantes :

  • Vous pouvez utiliser la propriété ThinkTimeMultiplier pour modifier la durée de veille.Par défaut, cette variable est égale à 1, mais vous pouvez l'augmenter ou la réduire pour modifier le temps d'attente dans le code.Par exemple, si vous effectuez des tests spécifiquement sur un réseau lent, ou des tests impliquant une diminution des performances, vous pouvez modifier cette variable à un endroit (ou même dans le fichier de configuration) sur 1,5 pour ajouter un délai attente supplémentaire de 50 % partout ailleurs.

  • Playback.Wait() appelle en interne Thread.Sleep() (après calcul ci-dessus) dans des plus petits segments dans une boucle for tout en recherchant l'opération cancel\break de l'utilisateur.En d'autres termes, Playback.Wait() vous permet d'annuler la lecture avant la fin du délai d'attente, tandis qu'avec la veille cela n'est pas le cas et peut lever une exception.

ConseilConseil

L'éditeur de test codé de l'interface utilisateur vous permet de modifier facilement les tests codés de l'interface utilisateur.À l'aide de l'éditeur de test codé de l'interface utilisateur, vous pouvez rechercher, afficher et modifier vos méthodes de test.Vous pouvez également modifier les actions d'interface utilisateur et leurs contrôles associés dans le mappage de contrôle d'interface utilisateur.Pour plus d'informations, consultez Modification des tests codés de l'interface utilisateur à l'aide de l'éditeur de test codé de l'interface utilisateur.

Conseils

Pour obtenir des informations supplémentaires, consultez Test de la livraison continue avec Visual Studio 2012 – Chapitre 5 : Automatisation des tests système (page éventuellement en anglais).

Voir aussi

Tâches

Procédures pas à pas : création, édition et gestion d'un test codé de l'interface utilisateur

Comment : insérer un délai avant l'action d'interface utilisateur à l'aide de l'éditeur de test codé de l'interface utilisateur

Concepts

Test de l'interface utilisateur avec des tests codés de l'interface utilisateur automatisés

Anatomie d'un test codé de l'interface utilisateur

Plateformes et configurations prises en charge pour les tests codés de l'interface utilisateur et les enregistrements des actions

Autres ressources

Création de tests codés de l'interface utilisateur