Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Nico Orschel
ist Software Process Consultant, Autor und Referent im Umfeld Microsoft ALM bei der AIT und wurde von Microsoft als MVP für VS ALM ausgezeichnet. Er hilft Unternehmen auf Basis von TFS effizienter Software zu entwickeln und zu testen und so ein höheres Qualitätsniveau bei kürzeren Release-Zyklen zu erreichen. Mein Profil auf Google+ .

Nico Orschel

Coded UI – WPF Anwendungen für CodedUI vorbereiten (Teil 2)

Donnerstag, 20. Januar 2011

In Teil 1 der Artikelserie haben wir Ihnen ein Werkzeug vorgestellt, um zu überprüfen, ob eine Anwendung  konform zu  den Standards UIA bzw. MSAA ist.  Im zweiten Teil betrachten wir die notwendigen Schritte, damit das CodedUI Framework besser die WPF Technologie (Windows Presentation Foundation) bzw. dessen Controls unterstützt.

WPF Anwendungen werden im Zusammenhang mit CodedUI über den Standard UIA angesprochen.

The Win32\Windows Forms control natively supported MSAA and not UIA whereas WPF supports UIA natively.  This is the reason for using MSAA for Win32\Windows Forms and UIA for WPF. [1]

Alle Standard-Controls aus dem .NET Framework (ab 3.0) werden durch das CodedUI Framework unterstützt.  Unabhängig von dieser generischen Microsoft-Aussage sind jedoch einige Vorbereitungen auf Seiten der Entwicklung notwendig. Damit das CodedUI-Framework in der Lage ist einzelne Controls über UIA zu verfolgen, muss der Entwickler die notwendigen Informationen über die Attached Property AutomationProperty nach außen bekannt machen. Die Verfolgung der UIA-Eigenschaften wird über ein Set von Search und Filter Properties realisiert.  Einen Überblick über die Tracking-Strategien vom UITest-Framework finden Sie unter [4].

Die Klasse AutomationProperty kennt dabei im Detail die folgenden Eigenschaften (siehe Klassendiagramm):

Klassendiagram AutomationProperty

Alle Details zu den einzelnen UIA Properties finden Sie unter [2].

Damit ein “Standard” WPF Control eindeutig vom UITest Framework gefunden werden kann, sollten Sie mindestens die Eigenschaft AutomationID setzen. Die Eigenschaft AutomationID ist dabei auf einen nicht lokalisierten Wert gesetzt (Beispiel: Control Name). Durch die Verwendung eines nicht lokalisierten Wertes ist die Identifizierung von Controls sprachenunabhängig.

Im Gegensatz zur AutomationID enthält die Eigenschaft AutomationName typischerweise einen lokalisierten Wert (Bsp.: angezeigter Button Text) und stellt somit die Ausgabe des Controls in einer UIA optimierten Form zur Verfügung.

Beispielcode (XAML).:

   1: <Button AutomationProperties.AutomationId="ButtonInsertCard" Grid.Row="1" Grid.Column="0" 
       Grid.ColumnSpan="1"  Margin="5" Command="{Binding Path=InsertCardCommand}">Insert Credit Card</Button>

Links und weiterführende Informationen

[1] Reason behind using MSAA and UIA: http://social.msdn.microsoft.com/Forums/en/vsautotest/thread/016e46e3-f7cd-46fb-9e12-728f4c846304

[2] Informationen über UIA Properties: http://msdn.microsoft.com/en-us/library/dd757479%28VS.85%29.aspx

[3] WPF Attached Property: http://msdn.microsoft.com/en-us/library/ms749011.aspx

[4] How does “Coded UI test” finds a control ??:  http://blogs.msdn.com/b/balagans/archive/2009/12/28/9941582.aspx

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , ,

Hinterlasse eine Antwort