Bringing the control into view is an essential part of the UITestAction during Playback since Coded UI Test performs actual Mouse/Keyboard actions on the control instead of programmatic action on the control. In case of failure to bring the control into view, the playback will throw a FailedToPerformActionOnBlockedControl exception or a PlaybackFailure exception.

 

The Coded UI Test playback engine attempts various approaches to bring the control into the physical screen view –

 

-          Bring the application window into the screen area

-          Set focus on the control.

-          Scroll the control into the view port of the container within which it resides.

 

This post focuses on the third approach and the assumptions made in the scrolling logic for Silverlight test automation in Coded UI Test.

 

 

To scroll a control into view,  the control (or its accessibility peer) should either support the scrolling capability natively,  or needs to be residing inside one or more scrollable containers which can then be scrolled in some sequence to bring the control into view.

 

Silverlight controls such as ListBoxItem or ComboBoxItem have their AutomationPeer implement IScrollItemProvider which is used to scroll the item into view. [The  ComboBox scroll into view in Coded UI Test is actually done through a select mechanism]

 

If a control does not implement scrolling support natively, the Playback engine relies on the scrolling capability of the containers. In Silverlight, a scrollable container can be defined using the ScrollViewer control.

 

    <ScrollViewer HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Auto">

        <Grid x:Name="LayoutRoot" Background="White" Height="400" Width="200">

            <Image Height="119" HorizontalAlignment="Left" Margin="61,40,0,0" Width="200" Source="/Image;component/Images/Desert.jpg" />

            <Image Height="150" HorizontalAlignment="Left" Margin="60,185,0,0" Width="200" Source="/Image;component/Images/Tulips.jpg" />

            <Image Height="41" HorizontalAlignment="Left" Margin="65,358,0,0" Width="200" Source="/Image;component/Images/Penguins.jpg" />

            <ScrollViewer Height="150" HorizontalAlignment="Left" Margin="446,519,0,0" Name="scrollViewer1" VerticalAlignment="Top" Width="300" >

                <TextBox Name="textBox1" />

            </ScrollViewer>

        </Grid>

    </ScrollViewer>

 

The Coded UI Test’s playback engine first attempts to perform programmatic scrolling using ScrollViewer.ScrollToVerticalOffset and ScrollViewer.ScrollToHorizontalOffset methods. In case it fails, or is not implemented in a custom ScrollViewer control, the scrolling will fall back to the next approach as described –

 

The Scroll Viewer control has a Horizontal Scroll Bar and Vertical Scroll Bar component with AutomationProperties.AutomationId properties set to “HorizontalScrollBar” and “VerticalScrollBar” respectively. Each of them in turn have 5 sub components  à Small Decrease Button, Large decrease Button, Thumb, Large Increase Button, Small Increase Button.

 

Following figure shows the AutomationProperties.AutomationId  properties of all the sub-components in the Scroll Viewer control.

 

 

The Playback engine identifies the scrollable container components using these AutomationProperties.AutomationId  properties and attempts to do the required scrolling using Mouse Click action on these sub components.

So, if you are implementing a custom scroll viewer, ensure that these default AutomationProperties.AutomationId  properties of the scroll viewer component are preserved in the respective custom control component.