Мы абстрагируемся от расположения элементов на форме и их внешнего вида, нам абсолютно не важно, что в разных OS кнопки имеют разный вид, мы тестируем только логику. Если нам нужно проверить, что после нажатия на кнопке изменилось значения label, то никакие дизайнерские изменения формы этот тест нам не поломают.
Итак, что же это нам дает:
Он для решения описанных выше проблем предлагает использовать библиотеку StoryText. Последняя перед запуском вашего приложения «оборачивает» интерфейсы обращения к библиотеке GUI, подсовывая программе свои варианты интерфейсов. Причем делается это совершенно прозрачно. В большинстве случаев, вам не придется менять ни единой строчки кода в тестируемом приложении. Это дает возможность при записи теста сохранять в лог действия пользователя и реакцию программы на эти действия. А при тестировании повторять действия пользователя и сравнивать реакцию программы с эталонной.
Какие же альтернативы предлагает TextTest?
Вариант второй «заточится» на некоторые тайные виджеты и как только они примут нужное состояние, считать, что действие выполнилось. Это добавляет работы программисту и делает тесты еще более нечитабельными и непонятными.
Можно делать таймаут, но тут проблема, что если страница в среднем загружается за 5 сек, то нужно «для верности» выставить таймаут раз в 5 больше, да и то не факт, что все отработает. Это приводит к замедлению тестов и к вероятностному характеру их выполнения.
И наконец, у обоих подходов есть общая проблема с тестированием не синхронных событий. Допустим, ввели в браузер URL, а когда проверять что страница загрузилась?
Зато тут уже легче тестировать логику работы GUI, мы не завязаны на графическое представление элементов, а имея хороший инструмент можно даже попытаться написать кроссплатформенные тесты.
не дают представления о том, что происходит и что собственно тестируется. Программисту нужно явно писать assert'ы, на то, что после допустим нажатия этой кнопки, вот это label изменил свое значение на такой, а вот этот не изменил. Так же API операционной системы может не предоставлять полного доступа к внутренностям виджетов, а уж если это нестандартный виджет, то считать его свойства становится практически невозможно.
ActivateWindow("Unsaved Document 1 - gedit")
У второго подхода другие проблемы тесты пишутся долго и сложно, а в добавок они зачастую совершенно непонятны окружающим, особенно непрограммистам. Портянки кода вроде этого:
Я не спорю внешний вид тестировать полезно, но это должны быть тесты только на оформление, тестировать через них логику работы GUI это издевательство над человеком.
Проблемы первых неустойчивость тестов, стоит изменить взаимное расположение кнопок на форме, даже на пару пикселей, упадет куча тестов, изменится разрешение экрана упадут все тесты, перешли на новую версию GUI-фрейморка, в которой, допустим, улучшили отрисовку шрифтов опять же упадут все тесты. Для каждой операционной системы нужно делать свой набор тестов, возможно, все придется переделывать даже после установки очередного сервис-пака, если он затронул графическую подсистему.
Предоставляют функции, которые через API операционной системы позволяют считывать параметры виджета
Делают скриншоты после каждого изменения экрана с последующим сравнением изменений
Сейчас подавляющее большинство инструментов тестирования GUI работают одним из двух способов:
Способы тестирования GUI
Продолжение рассказа о замечательном кроссплатформенном фрейворке для функционального-тестирования TextTest.
TextTest кроссплатформенный фреймворк на python для тестирования GUI и не только. Часть 2
TextTest кроссплатформенный фреймворк на python для тестирования GUI и не только. Часть 2 / Хабрахабр
Комментариев нет:
Отправить комментарий