Тестирование пользовательского функционала вебсайта с помощью Capybara page objects

Page Objects могут быть использованы как мощный метод абстракции (изоляции) ваших тестов от технической реализации. Важно помнить, их (Page Objects) можно использовать для увеличения стабильности тестов и поддержания принципа DRY (do not repeat yourself) — посредством инкапсуляции функционала (вебсайта) в простых методах.

Другими словами

Page Object — это экземпляр класса, который абстрагирует (изолирует) пользовательский интерфейс от тестовой среды, представляет методы для взаимодействия с пользовательским интерфейсом и извлекает необходимую информацию.

Терминология

Термин Page Object слишком обобщенное понятие. По моему опыту Page Object включает в себя следующие 3 типа:

• Component Objects представляет определенные компоненты или виджеты в пользовательском интерфейсе. Например: таблицы, меню, статьи и прочие блоки содержащие в себе группу компонентов.
• Page Object описывает определенную область, или пользовательский интерфейс в веб приложении. Он может состоять из нескольких Component Objects и может содержать удобные методы для взаимодействия с абстракцией, которая содержится внутри данного объекта.
• Experience используется для группировки сложного функционала, тестирование которого требует выполнения нескольких шагов, или взаимодействия с несколькими страницами. По своему опыту я использовал эту концепцию для абстракции сложного поведения на странице (тестирование обучающих страниц, создание нового пользователя и т.д.)

Примеры

Рассмотрим простой тест RSpec Capybara, который создает блоги и не использует объекты страницы:

require 'feature_helper'  feature 'Blog management', type: :feature do   scenario 'Successfully creating a new blog' do     visit '/'      click_on 'Form Examples'     expect(page).to have_content('Create Blog')      fill_in 'blog_title', with: 'My Blog Title'     fill_in 'blog_text', with: 'My new blog text'      click_on 'Save Blog'     expect(page).to have_selector('.blog--show')      expect(page).to have_content('My Blog Title')     expect(page).to have_content('My new blog text')   end    scenario 'Entering no data' do     visit '/'     click_on 'Form Examples'      expect(page).to have_content('Create Blog')      click_on 'Save Blog'      expect(page).to have_content('4 errors stopped this form being submitted')      expect(page).to have_content("Title can't be blank")     expect(page).to have_content("Text can't be blank")      expect(page).to have_content('Title is too short')     expect(page).to have_content('Text is too short')   end end

Рассмотрим код внимательнее, в нем есть несколько проблем. Здесь есть следующие действия: переход на соответствующую страницу, взаимодействие со страницей и проверка контента. Часть кода дублируется, но это можно исправить придерживаясь принципа DRY.

Важно понимать, что этот код трудно поддерживать, если есть изменения в тестируемом приложении. Например, классы элементов, имена и идентификаторы могут изменяться, что требует, регулярного потребует обновления кода теста.

Так же в этом коде нет ‘Семантического контекста’, трудно понять, какие строки кода логически сгруппированы.

Введение в Page Objects

Как обсуждалось в разделе терминологии, Page Objects могут использоваться для абстракций уровня представления.

Взяв предыдущий пример и применив Page Object для создания новых блогов и просмотра блогов, мы можем очистить код предыдущего примера.

Избавившись от конкретных сведений о технической реализации конечный результат (код) должны быть читабельным и не должен содержать конкретных сведений о пользовательском интерфейсе (id, css классы и т.д.).

require 'feature_helper' require_relative '../pages/new_blog' require_relative '../pages/view_blog'  feature 'Blog management', type: :feature do   let(:new_blog_page) { ::Pages::NewBlog.new }   let(:view_blog_page) { ::Pages::ViewBlog.new }    before :each do     new_blog_page.visit_location   end    scenario 'Successfully creating a new blog' do     new_blog_page.create title: 'My Blog Title',                          text: 'My new blog text'      expect(view_blog_page).to have_loaded     expect(view_blog_page).to have_blog title: 'My Blog Title',                                         text: 'My new blog text'   end    scenario 'Entering no data' do     new_blog_page.create title: '',                          text: ''      expect(view_blog_page).to_not have_loaded     expect(new_blog_page).to have_errors "Title can't be blank",                                          "Text can't be blank",                                          "Title is too short",                                          "Text is too short"   end end

Создание Page Objects

Первый шаг создания Page Objects это создание структуры basic page class:

module Pages   class NewBlog     include RSpec::Matchers     include Capybara::DSL      # ...   end end

Подключение (включение) Capybara :: DSL позволить экземплярам Page Objects использовать методы доступные в Capybara

has_css? '.foo' has_content? 'hello world' find('.foo').click

Кроме того, я использовал

include RSpec :: Matchers

в приведенных выше примерах, чтобы использовать RSpec библиотеку expectation.

Не стоит нарушать соглашения, Page Objects не должен включать в себя expect (ожидания). Однако где уместно я предпочитаю этот подход, чтобы полагаться на встроенные механизмы Capybara для обработки условий.

Например, следующий код Capybara будет expect (ожидать), наличия ‘foo’ внутри Page Objects (в данном случае это self):

expect(self).to have_content 'foo'

Тем не менее, в следующем коде:

expect(page_object.content).to match 'foo'

Возможны непредвиденные ошибки (возможно возникновение плавающего теста), так как page_object.content сразу проверяется на соответствие условию, и возможно, еще не объявлен. Для большего количества примеров я бы порекомендовал прочитать thoughtbot’s написание надежных асинхронных интеграционных тестов с Capybara.

Создание методов

Мы может абстрагировать (описать) место (область), из которой мы хотим получить данных, в рамках одного метода:

def visit_location   visit '/blogs/new'   # It can be beneficial to assert something positive about the page   # before progressing with your tests at this point   #   # This can be useful to ensures that the page has loaded successfully, and any   # asynchronous JavaScript has been loaded and retrieved etc.   #   # This is required to avoid potential race conditions.   expect(self).to have_loaded end  def has_loaded?   self.has_selector? 'h1', text: 'Create Blog' end

Важно выбрать семантически верные имена для методов для ваших Page Objects

def create(title:, text:)   # ... end  def has_errors?(*errors)   # ... end  def has_error?(error)   # ... end

В целом, важно следовать принципу функционально объединенных методов и, где возможно, придерживаться принципа единой ответственности (Single Responsibility Principle).

Component Objects

В нашем примере мы используем класс NewBlog, но реализация для создания отсутствует.

Поскольку мы взаимодействуем с формой, мы могли бы дополнительно ввести класс для представления этого компонента:

# ...  def create(title:, text:)   blog_form.new.create title: title,                        text: text end  # ...  private  def blog_form   ::Components::BlogForm end

Где может быть спрятана реализация методов для BlogForm:

module Components   class BlogForm     include RSpec::Matchers     include Capybara::DSL      def create(title:, text:)       within blog_form do         fill_in 'blog_title', with: title         fill_in 'blog_text', with: text          click_on 'Save Blog'       end     end      private      def blog_form       find('.blog--new')     end   end end

Все вместе

С помощью приведенных выше классов теперь можно запрашивать и создавать экземпляры объектов (Page Objects) вашей страницы в рамках описания объекта.

require 'feature_helper' require_relative '../pages/new_blog' require_relative '../pages/view_blog'  feature 'Blog management', type: :feature do   let(:new_blog_page) { ::Pages::NewBlog.new }   let(:view_blog_page) { ::Pages::ViewBlog.new }    # ... end

Примечание: Я намеренно создал объект страницы вручную в верхней части файла объектов. В некоторых RSpec тестах может быть удобно автоматически загружать все файлы поддержки и предоставлять доступ к ним в файлах объектов, однако это может привести к чрезмерным нагрузкам при использовании больших кусков кода. В частности, это приведет к медленному запуску и потенциальным непреднамеренным циклическим зависимостям.

Вызов Page Objects

Теперь в каждом сценарии у нас будет доступ к экземплярам new_blog_page и view_blog_page:

scenario 'Successfully creating a new blog' do   new_blog_page.create title: 'My Blog Title',                        text: 'My new blog text'    expect(view_blog_page).to have_loaded   expect(view_blog_page).to have_blog title: 'My Blog Title',                                       text: 'My new blog text' end

Naming Conventions / Predicate Methods

Как и в большинстве вещей в Rails / Ruby, существуют соглашения, которые могут показаться незначительными (не обязательными к исполнению) полностью с первого взгляда.

В наших тестах мы взаимодействовали с объектом страницы с помощью have_loaded и have_blog:

expect(view_blog_page).to have_loaded expect(view_blog_page).to have_blog title: 'My Blog Title',                                     text: 'My new blog text'

Тем не менее, имена методов нашего объекта страницы на самом деле has_loaded? и has_blog?:

def has_loaded?   # ... end  def has_blog?(title:, text:)   # ... end

Это тонкое различие, на которое нужно обратить внимание. Для получения более подробной информации об этом соглашении я бы рекомендовал к прочтению следующую ссылку predicate matchers.

Git, исходный код используемый в примерах
Оригинал