The last post dealt with ASP.NET and Silverlight technologies with respect to creating CodedUI Scripts and their subsequent playback. This post addresses the remaining two, i.e. Winforms and WPF.
It is probably easiest to create CodedUI scripts for a Winforms application: most of the controls on the form are read correctly, and actions once recorded are played back consistently, which makes life pretty easy.
ComponentOne Winforms controls also support CodedUI tests, hence they can have the script actions and playbacks done and they more expose most of their attributes for assertions using the CodedUI Test Builder.
There are still areas where using a different implementation helps in letting UICoder read our applications better, faster, thus making our Automated Tests more effective.
If your application uses C1 controls within wrapper or custom classes, there may be some issues, while reading them using CodedUITest Builder.
Tip: Using controls within custom classes hides most of their exposed properties from UICoder. In case an application is built with future automation in mind, explicitly set some properties of contained controls so that they are easily identified.
Even in Winforms applications, sometimes mouse actions are not read correctly.
Tip: Assigning and using keyboard shortcuts can be a good workaround, as they are not restricted by coordinates on the screen.
While creating an application, we tend to leave keyboard interaction out of our UI, restricting their use for just text boxes, but when it comes to automation using UICoder, keyboard actions are much more consistent than those recorded using mouse.
These also come in handy if the application uses lots of Menus and Command controls. It is highly suggested that we follow the approach of using keyboard actions, since mouse actions no longer remain consistent with menus if they go more than three levels down.
For more details regarding creating CodedUI scripts for Winforms applications you can refer to the following post as well:
Although I have not seen too much activity on this front, i.e. WPF and UICoder, its still worth mentioning how well ComponentOne suites work in both.
The most popular controls are the Grid controls, as they are used in all platforms; it is on that I would like to shed some light.
One of the most common problems faced with WPF applications and UICoder is the problem of incorrect focus. During our tests, we observed that occasionally the sample application was not recognized, rather the scripts started playing back on any other window open on the desktop because focus had shifted.
Tips: Upon starting the test runs, minimize any other windows open on the desktop; better yet, close any windows that are not needed. The practice should be to keep only the sample application open.
Most of the other tips between Winforms and WPF remain the same, the only other important aspect here as well are the AutomationId's which stems from the fact the WPF uses XAML at the back end.
Tip : Specifying Automation Id for individual controls
Automation Id is a property provided with every control, when its declared in XAML. This property makes the controls uniquely identifiable among other controls of the same type on the page.
It's fairly easy to assign an AutomationID to control, as is given in the code below,
<c1chart:C1Chart AutomationProperties.AutomationId="C1Chart1" Height="341" HorizontalAlignment="Left" Margin="189,12,0,0" Name="chart" VerticalAlignment="Top" Width="548">
<c1chart:ChartData ItemNames="P1 P2 P3 P4 P5">
<c1chart:DataSeries Label="Series 1" Values="20 22 19 24 25" />
<c1chart:DataSeries Label="Series 2" Values="8 12 10 12 15" />
<c1chart:C1ChartLegend DockPanel.Dock="Right" />
Once this is specified, it becomes quite easy for the CodedUI Test build to recognize WPF controls present on the page.
For more details about AutomationID property, you can follow the link below,
In case you face any issues while using CodedUI tests with ComponentOne controls, feel free to contact our support team on the ComponentOne Support Forums: