Making Coded UI Tests Wait For Specific Events During Playback

  • Artikel

Sie können bei der Wiedergabe eines Tests der codierten UI festlegen, dass bei einem Test auf bestimmte Ereignisse gewartet werden soll, z. B. auf das Anzeigen eines Fensters, das Ausblenden einer Statusanzeige usw. Verwenden Sie hierzu die entsprechende UITestControl.WaitForControlXXX()-Methode, wie in der folgenden Tabelle beschrieben. Ein Beispiel für einen Test der codierten UI, bei dem bei einem Steuerelement darauf gewartet wird, dass es mithilfe der WaitForControlEnabled()-Methode aktiviert wird, finden Sie unter Exemplarische Vorgehensweise: Erstellen, Bearbeiten und Verwalten von Tests der codierten UI.

UITestControl.WaitForControlXXX()-Methoden

UITestControl.WaitForControlXXX()-Methoden

Beschreibung

WaitForControlReady()

Wartet, bis für das Steuerelement Maus- und Tastatureingaben vorgenommen werden können. Das Modul ruft implizit diese API auf, damit mit allen Aktionen gewartet wird, bis mit dem Steuerelement Vorgänge ausgeführt werden können. In bestimmten vertraulichen Szenarien müssen Sie womöglich einen expliziten Aufruf ausführen.

WaitForControlEnabled()

Wartet, bis das Steuerelement aktiviert wird, wenn der Assistent eine asynchrone Validierung der Eingabe durch Aufrufe an den Server ausführt. Sie können z. B. eine Methode verwenden, damit gewartet wird, bis die Schaltfläche Weiter des Assistenten aktiviert ist (). Ein Beispiel für diese Methode finden Sie unter Exemplarische Vorgehensweise: Erstellen, Bearbeiten und Verwalten von Tests der codierten UI.

WaitForControlExist()

Wartet, bis das Steuerelement auf der Benutzeroberfläche angezeigt wird. Sie warten z. B. darauf, dass ein Fehlerdialogfeld angezeigt wird, nachdem die Anwendung die Validierung der Parameter durchgeführt hat. Die für die Validierung benötigte Zeit variiert. Sie können mithilfe dieser Methode auf das Fehlerdialogfeld warten.

WaitForControlNotExist()

Wartet, bis das Steuerelement von der Benutzeroberfläche verschwindet. Sie können z. B. warten, bis die Statusanzeige ausgeblendet wird.

WaitForControlPropertyEqual(String, Object)

Wartet, bis die auf dem Steuerelement angegebene Eigenschaft den festgelegten Wert erreicht. Sie warten beispielsweise, bis der Statustext Fertig lautet.

WaitForControlPropertyNotEqual(String, Object)

Wartet, bis die auf dem Steuerelement angegebene Eigenschaft das Gegenteil eines festgelegten Werts erreicht. Sie warten beispielsweise, bis das Eingabefeld nicht schreibgeschützt, also bearbeitbar, ist.

WaitForControlCondition(Predicate<UITestControl>)

Wartet, bis die angegebenen Prädikatrückgaben true sind. Diese Option kann für komplexe Wartevorgänge (wie OR-Bedingungen) für ein bestimmtes Steuerelement verwendet werden. Sie können beispielsweise warten, bis der Statustext Erfolgreich oder Fehler lautet, wie im folgenden Code dargestellt:

// 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<T>(T, Predicate<T>)

Alle vorherigen Methoden sind Instanzmethoden von UITestControl. Dies ist eine statische Methode. Mit dieser Methode wird außerdem darauf gewartet, dass das angegebene Prädikat true ist. Sie kann jedoch auch für komplexe Wartevorgänge (wie OR-Bedingungen) für mehrere Steuerelemente verwendet werden. Sie können z. B. warten, bis der Statustext Erfolgreich lautet oder eine Fehlermeldung angezeigt wird, wie im folgenden Code dargestellt:

// 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);

All diese Methoden weisen folgendes Verhalten auf:

  • Die Methoden geben "true" zurück, wenn der Wartevorgang erfolgreich war, und "false", wenn dabei ein Fehler aufgetreten ist.

  • Das implizite Timeout für den Wartevorgang wird von der WaitForReadyTimeout-Eigenschaft angegeben. Der Standardwert dieser Eigenschaft ist 60000 Millisekunden (eine Minute).

  • Die Methoden verfügen über eine Überladung für ein explizites Timeout in Millisekunden. Wenn der Wartevorgang jedoch zu einer impliziten Suche nach dem Steuerelement führt, oder wenn die Anwendung ausgelastet ist, kann die tatsächliche Wartezeit länger sein als das angegebene Timeout.

Die vorherigen Funktionen sind leistungsstark und flexibel und sollten fast alle Bedingungen erfüllen. Falls diese Methoden die Anforderungen jedoch nicht erfüllen und Sie Wait(Int32) oder Sleep(Int32) im Code angeben müssen, sollten Sie die Playback.Wait()-API anstelle der Thread.Sleep()-API verwenden. Gründe:

  • Mit der ThinkTimeMultiplier-Eigenschaft können Sie die Dauer des Standbymodus ändern. Standardmäßig ist für diese Variable "1" festgelegt. Sie können jedoch einen höheren oder niedrigeren Wert festlegen, um die Wartezeit im gesamten Code zu ändern. Wenn Sie z. B. ausdrücklich langsame Netzwerke oder einen anderen langsamen Leistungsfall testen, können Sie für diese Variable an einer Position (oder sogar in der Konfigurationsdatei) "1,5" festlegen, um an allen Positionen 50 Prozent zusätzliche Wartezeit hinzuzufügen.

  • Playback.Wait() ruft Thread.Sleep() (nach der oben aufgeführten Berechnung) intern in kleineren Ausschnitten in einer For-Schleife auf und überprüft gleichzeitig durch den Benutzer abgebrochene oder angehaltene Vorgänge. Mit anderen Worten: Sie können mithilfe von Playback.Wait() die Wiedergabe vor dem Ende des Wartevorgangs abbrechen, wohingegen der Standbymodus die Wiedergabe nicht abbricht oder eine Ausnahme auslöst.

Tipp

Mit dem Editor für den Test der codierten UI können die Tests der codierten UI mühelos geändert werden. Er ermöglicht das Suchen, Anzeigen und Bearbeiten der Testmethoden. Sie können auch UI-Aktionen und die zugehörigen Steuerelemente in der UI-Steuerelementzuordnung bearbeiten. Der Editor für den Test der codierten UI ist in Microsoft Visual Studio 2010 Feature Pack 2 enthalten. Zum Herunterladen des Feature Packs benötigen Sie Visual Studio 2010 Ultimate, Visual Studio 2010 Premium oder Test Professional 2010 mit einem MSDN-Abonnement, Microsoft BizSpark oder MSDN Academic Alliance. Weitere Informationen finden Sie unter Bearbeiten von Tests der codierten UI mithilfe des Test-Editors für codierte UI und Microsoft Visual Studio 2010 Feature Pack 2.

Siehe auch

Aufgaben

Gewusst wie: Erstellen eines Tests für codierte UI

Konzepte

Testen der Benutzeroberfläche mit automatisierten UI-Tests

Unterstützte Konfigurationen und Plattformen für Tests der codierten UI und Aktionsaufzeichnungen

Weitere Ressourcen

Exemplarische Vorgehensweise: Erstellen, Bearbeiten und Verwalten von Tests der codierten UI

Anatomy of a Coded UI Test