В теме одно сообщение

[edd1977]

В данный момент оптимизирую свой тестовый проект для приложения на Silverlight 5. Использую классы из UITesting (в редких случаях из UI Automation). Как вариант оптимизации и повышения устойчивости, решил проставить методы вида WaitForControlXXX в необходимых на мой взгляд местах. И первое, с чем столкнулся - мое ожидание того как эти методы должны работать расходится с практическим результатом.

Поясню на примере: создал простой UserControl в Silverlight, который состоит из двух кнопок, одна из которых при запуске не видна. При нажатии на первую кнопку (First) становится видна вторая - Second. А при нажатии на Second программно добавляется третья кнопка - Third. Сделал сопутствующий CodedUITest-проект, в котором планировал проверить работу методов класса UITestControl: WaitForControlPropertyNotEqual (для кнопки Second) и WaitForControlExists - для кнопки Third.

 

Silverlight-контрол очень простой (развертывается в простом Web-проекте и запускается в браузере):

 

<Grid x:Name="LayoutRoot" Background="White">

        <Button HorizontalAlignment="Left" VerticalAlignment="Top"

                AutomationProperties.AutomationId="btnFirst"

                Click="Button_Click"

                Name="btnFirst"

                >First</Button>

        <Button HorizontalAlignment="Right" VerticalAlignment="Top"

                AutomationProperties.AutomationId="btnSecond"

                Click="Button_Click_1"

                Visibility="Collapsed"

                Name="btnSecond"

                >Second</Button>

    </Grid>

 

Процедура Button_Click делает: btnSecond.Visibility = Visibility.Visible; // делаем кнопку видимой

Процедура добавления 3-й кнопки (Button_Click_1), так же проста:
 

Button btn = new Button();

            btn.Name = "btnThird";

            btn.Content = "Third";

            btn.HorizontalAlignment = HorizontalAlignment.Left;

            btn.VerticalAlignment = VerticalAlignment.Bottom;

            //

            LayoutRoot.Children.Add(btn);

 

Теперь самое главное, что я ожидал и что я получил. Тестовый метод выглядит следующим образом:

 

WaitForXxxxMapClasses.WaitForXxxxMap uimap = new WaitForXxxxMapClasses.WaitForXxxxMap(); // моя UIMap, которую я получил с помощью UI test builder.

            //

            SilverlightButton first = uimap.UIWaitForXxxxTestingInWindow.UIWaitForXxxxTestingDocument.UISilverlightControlHoPane.UIItemCustom.UIMainPageMainPage.UIFirstButton;

            SilverlightButton second = uimap.UIWaitForXxxxTestingInWindow.UIWaitForXxxxTestingDocument.UISilverlightControlHoPane.UIItemCustom.UIMainPageMainPage.UISecondButton;

            SilverlightButton third = uimap.UIWaitForXxxxTestingInWindow.UIWaitForXxxxTestingDocument.UISilverlightControlHoPane.UIItemCustom.UIMainPageMainPage.UIThirdButton;

            //

            second.WaitForControlPropertyNotEqual(UITestControl.PropertyNames.Height, 0); // Исследуемая функция.

            //

            Rectangle rect = second.BoundingRectangle;

            Point center = new Point();

            center.X = rect.Left + rect.Width / 2;

            center.Y = rect.Top + rect.Height / 2;

            //

            Mouse.Click(center);

 

Я ожидал, что метод WaitForControlPropertyNotEqual для кнопки second должен блокировать ход выполнения тестового метода до тех пор, пока высота кнопки не станет больше 0 (т.е. кнопка станет видимой) или пока не кончится время по умолчанию. В MSDN написано так: Blocks the current thread until the specified property of this control is not equal to the specified value, or until the default time-out expires./

Конечно я проверил значение Height - оно равно 0 и параметры объекта Playback.PlaybackSettings, вот они на момент выполнения метода:

Test Name: Parameters

Test Outcome: Passed

Result StandardOutput:

DelayBetweenActions = 100

SearchTimeout = 120000

WaitForReadyTimeout = 60000

ShouldSearchFailFast = True

SmartMatchOptions = TopLevelWindow, Control

SearchInMinimizedWindows = True

ThinkTimeMultiplier = 1

ImeLanguageList = System.Collections.Generic.List`1[System.Int32]

MaximumRetryCount = 1

MatchExactHierarchy = False

SkipSetPropertyVerification = False

SendKeysAsScanCode = False

WaitForReadyLevel = UIThreadOnly

ContinueOnError = False

AlwaysSearchControls = False

 

Как я понял, функция должна ожидать WaitForReadyTimeout милисекунд и уже потом завершаться ошибкой. Я же планировал нажать на первую кнопку спустя несколько секунд после старта теста и увидеть, как тест нажмет на вторую кнопку, чтобы появилась третья :). Но все оказалось не так...

 

На самом деле: WaitForControlPropertyNotEqual ничего не ждет - алгоритм продолжается без всяких видимых! пауз и пытается нажать на кнопку, у которой нулевые высота и ширина, а BoundingRectangle вообще с отрицательными величинами (глянул на всякий случай). И сразу появляется ошибка:

...Microsoft.VisualStudio.TestTools.UITest.Extension.PlaybackFailureException: Cannot perform 'Click' on the control. Additional Details: The control details were not specified. ...

 

А если используем такое нажатие: Mouse.Click(second);, то ошибка примерно все равно о том же: ... 

Microsoft.VisualStudio.TestTools.UITest.Extension.FailedToPerformActionOnHiddenControlException: Cannot perform 'Click' on the hidden control. Additional Details: ...

 

Тогда возникает вопрос... а как тогда должны работать функции ожидания для UITestControl? Как их надо применять, чтобы отрабатывала задержка по времени и тест не валился, если вдруг что-то не успеет огтрисоваться или загрузиться в процессе запуска?

 

PS я пробовал и такой вариант: second.WaitForControlPropertyNotEqual(UITestControl.PropertyNames.Height, 0, 60000); - никакой разницы, все пролетает за считанные секунды и ошибки те же.

 

[edd1977]

В результате экспериментов над простыми формами и ЭУ пришел к следующему выводу:

 

функции WaitForControlXXX работают следующим образом: они действительно останавливают текущий поток (тот самый, которому принадлежит алгоритм тестового метода), при этом возможны исходы:

1. условие выполнилось и мы досрочно прервали ожидание и пошли по алгоритму дальше.

2. Условие не выполнилось, но закончился интервал ожидания, который скорее всего равен WaitForReadyTimeout * ThinkTimeMultiplier (по факту у меня интервал немного превышал 1 мин, но о возможном превышении где-то пишется и в msdn).

При этом для 2), если условие не выполнилось, а интервал превышен - никаких остановок и исключений не будет - тихо и молча алгоритм побежит дальше, как и в случае 1.

Рабочей оказались такого рода конструкции:

 

while (!third.Exists)

  third.WaitForControlExist();

...

while (!third.Enabled)

  third.WaitForControlEnabled();

...

 

Особо остановлюсь на свойстве Enabled. Мне казалось, что оно будет ложным, если ЭУ не видим (Visible = Collapsed), однако я жестоко ошибся и у контролов, которые спрятаны Enabled = true, что объясняло поведение программы, описанное в теме. Поскольку проверки на видимость в стандартной библиотеке UITesting нет, пришлось найти эквивалент. У меня он заработал на 100%, если кто-то знает как сделать прнавильнее - поделитесь идеей. Я сделал так:

 

while (!ConditionVisible(second))

  second.WaitForControlCondition(ConditionVisible);

Mouse.Click(second);

, где условие такая функция:

 

bool ConditionVisible(UITestControl ctrl)

        {

            Point pt = new Point();

            return ctrl.TryGetClickablePoint(out pt);

        }

 

Теперь все работает, как я и предполагал в заголовке своего сабжекта: тест запускается и ждет, пока я не нажму кнопку 1. После чего кнопка 2 стаановится видимой и нажимается автоматически, что приводит к появлению кнопки 3, на которую так же можно будет нажать из теста.