Сегодня про проверку видимости и доступности кнопок на форме. И в частности про обнаружение ошибок путем их подтверждения действиями над другими элементами формы: когда заранее ожидаемой ошибке присваивается статус «Не является ошибкой», а в зависимости от результата прохождения следующего шага теста выводится итоговое суждение - является ли заранее ожидаемая ошибка ошибкой или нет.
Второе предложение звучит мудрено и запутано? Но интересно. Будем разбираться.
Для начала ознакомимся с условием решаемой задачи. Как в «Сказке о царе Салтане» было три девицы под окном, так и у нас есть форма с тремя видами кнопок:
- Первый вид. Кнопка видна на форме и на нее можно нажать. Результатом данного нажатия будет открытие другой формы.
- Второй вид. Кнопка видна на форме, но недоступна для нажатия. Неактивна.
- Третий вид. Кнопка скрыта с формы.
Необходимо написать сценарный автотест, который должен подтвердить что:
- Первый вид кнопки присутствует на форме и доступен для нажатия.
- Второй вид кнопки присутствует на форме, но не доступен для нажатия.
- Третий вид кнопки отсутствует на форме.
Звучит несложно.
Для начала посмотрим какие виды проверок можно выполнить шагами инструмента «1С:Сценарное тестирование» для элемента «Кнопка»:
- Проверить доступность для работы
- Проверить недоступность для работы
- Проверить отсутствие
- Проверить свойства
- Проверить существование
А теперь подберем проверки под каждый вид кнопки.
Первый вид: кнопка видна на форме и на нее можно нажать.
Самая простая и надежная проверка для данной кнопки - это просто нажать на нее. Если в результате открывается ожидаемая форма, то проверка прошла успешно. Если нет, значит с кнопкой что-то не так.
Это самый распространенный способ проверки, потому что так построена логика сценарной проверки «действие - результат»: нажимается кнопка, открывается форма, тем самым подтверждая работоспособность кнопки, а далее продолжается работа с данной формой.
Другой способ - это использовать действие «Проверить доступность для работы». Данная проверка проходит успешно, если кнопка видна на форме и на нее можно нажать.
Третий вариант - применить действие «Проверить свойства». Достаточно проверить, что свойства «Видимость» и «Доступность» будут установлены в значении «Да». Но дополнительно можно добавить проверку и других свойств.
Есть еще действие «Проверить существование». Но оно не отвечает на вопрос работоспособности кнопки. Потому, в данном случае, не подходит.
Второй вид: кнопка видна на форме, но недоступна для нажатия.
Первый способ - «Проверить недоступность для работы». Если кнопка видна на форме, но недоступна для нажатия, то проверка проходит успешно. Иначе кнопка активна.
Вторым способом будет знакомое действие «Проверить свойства», которое уже было описано выше. В данном случае, свойство «Видимость» будет в значении «Да», а «Доступность» в значении «Нет».
А теперь немного интересного. Про то мудреное и запутанное предложение в начале статьи.
Встретилась в нашем примере кнопка, которая на форме визуально неактивна, но при этом свойства «Видимость» и «Доступность» у нее установлены в значении «Да».
Оказалось, что данная кнопка входит в состав обычной группы и использует ее свойства: «Видимость» - «Да», а «Доступность» - «Нет». То есть доступность кнопки ограничили не на уровне самой кнопки, а на уровне группы, в которую она входит.
Что это означает?
Что действия «Проверить недоступность для работы» и «Проверить свойства» именно для данной кнопки применить не получится. Фактически кнопка неактивна, а по свойствам активна.
Что делать?
Правильным вариантом было бы свалиться как снег на голову разработчику и напомнить ему, что рекомендуется управлять доступностью на уровне элементов, а не групп. И после исправления спокойно использовать действия «Проверить недоступность для работы» или «Проверить свойства».
Не стали тратить время разработчиков на исправление формы, потому что проверяемая форма использовалась только в тестовой базе и пользователи с ней не взаимодействуют. Решили использовать возможности инструмента «1С:Сценарное тестирование».
Самым простым, но не сразу очевидным, оказался способ «Проверить недоступность для работы» именно для группы, в которую входит неактивная кнопка. Раз она берет свойства от родителя, то и проверять надо свойства родителя. Это сработало корректно.
А вот второй способ, как раз про то самое обнаружение ошибки через подтверждение действиями над другими элементами. Скорее всего может сложиться впечатление, что способ усложнен и запутан. Но мне он понравился своей нестандартностью. Потому и хочу им поделиться.
Как построили проверку?
- Первый шаг в сценарии проверяет неактивную кнопку через действие «Нажать». Поведение при ошибке у него установлено в значение «Не является ошибкой».
- Второй шаг сценария производит действие «Нажать» для другой кнопки, которая видна на форме и доступна для нажатия.
Как строилось рассуждение?
Поведем рассуждение от негативного исхода теста. Если кнопка стала активной, то первый шаг сможет на нее нажать, а значит откроется новая форма, которая станет активной. Соответственно второй шаг сценария уже не сможет нажать на вторую кнопку, которая осталось на прошлой форме и завершится с ошибкой.
Это и есть подтверждение: второй шаг завершился с ошибкой, потому что в первом шаге было неверное поведение.
Поведение при ошибке в значении «Не является ошибкой» необходимо именно для положительного исхода автотеста, когда на кнопку нельзя нажать и соответственно шаг «Нажать» должен обязательно «упасть». Данное поведение использовано специально, чтобы автотест перешел к выполнению следующего шага.
Сразу возникают вопросы к надежности этой проверки:
Проверяется недоступность кнопки. А что, если она будет вообще скрыта с формы?
Для нашего примера проверяется именно недоступность кнопки. А каким именно способом: не активностью или скрытностью - не важно. На логику выполнения автотеста это так же не влияет, так как шагу, который производит нажатие на кнопку заранее присваивается поведение «не ошибки».
Если надо проверять, что кнопка именно неактивна, но видна на форме, то данный способ не подойдет и надо использовать проверку недоступности группы.
А если кнопка окажется «пустышкой»: нажимается, но при этом ничего не происходит? Форма не открывается.
Такое поведение кнопки все равно отвечает требованиям проверки, потому что проверка заключается в том, чтобы по нажатию на данную кнопку не открывалась форма.
Как это будет выглядеть в отчете о прохождении автотеста? Ошибка не на уровне проверяемой кнопки, а ниже.
Да, тут есть явное неудобство. Ошибка в отчете всегда фиксируется не на проверяемом шаге, а на следующем. Мало того, этот следующий шаг может еще и со своей ошибкой «упасть». К тому же, если специалист, который занимается тестированием данной формы, не предупрежден о данной особенности, то может потерять время на разбор данного «падения» автотеста.
Для решения данных моментов было решено вынести проверку данной кнопки в отдельный автотест с комментарием об его особенностях.
Почему используется поведение «Не является ошибкой», а не «Продолжить выполнение»?
По причине, описанной выше: чтобы отчет о выполнении сценария было легче прочитать и понять. Если ошибка произошла на втором шаге, то останется только понять - это подтверждение ошибки предыдущего шага или ошибка текущего шага.
Но использовать поведение «Продолжить выполнение» тоже возможно, так как при нем сценарий так же продолжит свое выполнение.
Третий вид: кнопка скрыта с формы.
Самая очевидная проверка для данного вида кнопок - это действие «Проверить отсутствие». Если кнопка скрыта с формы, то проверка проходит положительно. Иначе она имеет место на форме.
Если кнопка скрыта, то по логике она должна быть автоматически и недоступна для работы. Потому вполне можно записать вторым способом - действие «Проверить недоступность для работы».
И третье место достается самому универсальному действию «Проверить свойства». Для данного вида кнопки оба свойства будут в значении «Нет».
Подведем итог
Для проверок всегда стоит выбирать логичные и очевидные действия.
Так для проверки видимых на форме и доступных для нажатия кнопок можно использовать действия:
- «Нажать»
- «Проверить доступность для работы»
- «Проверить свойства»
Для видимых на форме кнопок, но недоступных для нажатия:
- «Проверить недоступность для работы»
- «Проверить свойства»
А для скрытых с формы кнопок:
- «Проверить отсутствие»
- «Проверить недоступность для работы»
- «Проверить свойства»
Но встречаются и особенности. Как в нашем примере про кнопку, которая брала свойства от группы.
Повторюсь, что, в первую очередь, про такие ситуации стоит сообщать разработчикам. Исправлять. А потом уже составлять сценарий тестирования.
Но, если возникают допущения, которыми можно пренебречь, то уместно прибегнуть и к не совсем привычным логическим построениям проверки. Главное, чтобы конечный пользователь не страдал от качества такой проверки, а специалисты могли быстро и точно идентифицировать место ошибки.