Спасибо Вам, наши читатели, за теплые отзывы о полезных ссылках. Встречайте список рекомендованных статей на эту неделю:

• Selenium: работаем с элементами страницы, используя @FindBy и PageFactory
• Уроки Python от Google
• Создаем кастомные шаги в SoapUI
• SST Selenium фреймворк на Python
• Selenium новости №77
• Ядро универсального keyword-driven фреймворка
• Очень простой и легкий инструмент тестирования консистенции сайта на разных браузерах
• Selenium новости №78
• И еще одни Selenium новости №79
• Selenium Tutorial for Beginners
• Автоматизация с помощью Selenium и Selenium Grid часть 1, часть 2, часть 3

Существует несколько специфических трендов, наметившихся в том, как мы производим автоматизацию тестов на основе пользовательского интерфейса. Технологии ушли вперед, были созданы новые интерфейсы, и в результате, также были созданы и новые инструменты, для того, чтобы «парировать этот удар» и, таким образом автоматизация тестирования была изменена.

Эволюция

Давайте немного вернемся назад и посмотрим, как развивались инструменты и фреймворки по автоматизации тестирования. 

• Главным в любом фреймворке автоматизации является процессор ядра системы. 
• Традиционный набор инструментов записи и воспроизведения находится над этим ядром. 
• Так как скрипты, сделанные с помощью record&playback, имели проблемы с устойчивостью и сложностью, поэтому это стало причиной того, что был добавлен новый слой – а именно самописные фреймворки

Увидел новость что некоторые ребята сделали фреймворк и описали его: 

GREATS is a framework that:

• Is Object Oriented and follows integrated Hybrid Concept
• Has no record and play
• Has longevity and easy maintenance
• Uses Open Source Automation tool “Selenium”.
• Stores Test automation workflows, test object definition and description in xls format
• Logs customized results and errors.
• Keyword-Driven Framework
• Test Script Modularity Framework
• Data-Driven Testing Framework

Что означает "integrated Hybrid Concept"? У меня есть догадки что это смесь Keyword-Driven и Data-Driven, но не свовсем уверен. Есть какие-то предположения?

Зачастую решение по автоматизированному тестированию становится достаточно сложным, что для написания тестов и всего вспомогательного кода требуются навыки программирования, причем иногда даже не начального уровня, а немного повыше. В то же время, имеет место тенденция к упрощению работы с автотестами. Это достигается путем добавления различных визардов, созданию определенных подходов и движков, реализующих данный подход. В частности популярен т.н. keyword-driven подход, когда тесты представляют собой последовательность ключевых слов, структурированную в таблицах. Но есть еще более заковыристый подход, при котором тесты представляются в виде обычных инструкций, написанных в виде обычного текста, для которых есть определенная реализация на уровне программного кода. Для Ruby есть такой движок, именуемый Cucumber.

Итак, допустим, у нас есть некоторый тестовый сценарий, описанный в виде:

• Login into the system
• Click on "Search" button
• Search screen is displayed

Сразу стоит отметить, что сценарий взят с потолка. Мы рассматриваем некоторое "сферическое приложение в вакууме", у которого есть функциональность для залогинивания, а также есть некоторый функционал поиска. Допустим, на Ruby этот тест реализуется в виде:

app.login
app.click_button "Search"
assert app.search_screen_displayed? , "No search screen available"

Исходим из предположения, что весь необходимый для выполнения данного сценария функционал у нас есть. Вот так вот компактно можно реализовать данный тест. Но это просто и легко для тех, кто программирует на Ruby. А теперь представим, что у нас есть тест-дизайнер, который просто пишет сценарии. Как сделать так, чтобы ему можно было создавать тесты, которые можно было бы запускать автоматически? Вот подобными вещами Cucumber и занимается.

Что это такое? По сути - это текстовый парсер, который оперирует определенными текстовыми конструкциями и определенному тексту ставит в соответствие некоторый блок программного кода на Ruby. Этот модуль предоставляется как отдельный gem. Чтобы его установить надо выполнить командную строку:

gem install cucumber

Итак, исходя из определения, у нас есть обычный текст теста и поставленные в соответствие определенным фразам блоки кода. То есть имеет место разделение описания и реализации. В Cucumber это выражается в том, что описание тестов хранится в файле с расширением *.feature, а сама реализация находится в файле с расширением *.rb. Более того, файлы формируются исходя из определенной структуры каталогов. Вообще, Cucumber работает со структурой сформированной по следующим правилам:

• Главный каталог, содаржащий описание тестов и их реализацию именуется features именнов этом каталоге и во всех вложенных каталогах могут находиться feature-файлы
• Все Ruby-реализации инструкций находятся в подкаталоге features/step_definitions и во всех вложенных подкаталогах
• Вспомогательный функционал находится в подкаталоге features/support
• В подкаталоге features/support находится файл env.rb, который отвечает за функционал, выполняемый до/после тестов, какие-то настройки и т.п. Это отдельная тема.

Итак, определившись со структурой, можем создать определение нашего теста. В каталоге features создадим файл sample.feature и напишем определение теста вот так:

Feature: Cucumber sample testing
    Scenario: Sample scenario
        Given Login into the system
        When Click on "Search" button
        Then Search screen is displayed

Вот пример описания теста в Cucumber. Здесь жирным шрифтом отмечены 5 ключевых слов (это не все ключевые слова, но наиболее часто используемые):

• Feature: - просто содержит описание группы тестов
• Scenario: - предшествует имени теста
• Given - обозначает, что инструкция за этим словом - это некоторые предварительные настройки или начальное состояние
• When - обозначает, что инструкция за этим словом - это некоторые некоторое действие, которое надо выполнить
• Then - обычно предшествует инструкциям, отвечающим за верификации

Теперь, добавим реализацию данных шагов. В подкаталоге features/step_definitions создадим файл sample.rb и впишем в него следующее:

require \'test/unit/assertions\'

World(Test::Unit::Assertions)

Given "Login into the system" do
  app.login
end

When  "Click on \\"Search\\" button" do
  app.click_button "Search"
end

Then "Search screen is displayed" do
  assert app.search_screen_displayed? , "No search screen available"
end

Всё, пример готов. Теперь запустим. Cucumber-тесты запускаются из командной строки вида:

cucumber <features_folder>

Перейдем в каталог, в котором находится каталог </b>features</b> с нашими определениями тестов и запустим командную строку вида:

cucumber features

Пойдет выполнение тестов и все выполненные шаги будут по умолчанию выводиться в консоль (различные виды логгирования в Cucumber стоит рассмотреть отдельно). Примерно так это и работает. Ну, и добавим немного "гибкости" в наш код. Как видно из примера, вызов

app.click_button "Search"

по дизайну расчитан на то, что нужная кнопка будет находиться по определенному тексту. То есть если нам надо будет нажать на кнопку, например, "Select", то это будет реализовано вызовом

app.click_button "Select"