页面对象模型，方法有多么离散？

Question

所以我一直在新项目上实施PoM，这将是我第一次这样做。我使用Capybara和Rspec（Selenium）来编写我的框架。

我经常遇到的一件事是我应该如何“离散”在我的Page Object Classes中创建方法。在谈到这个问题时，我看到了两个思路：

让我们看一个制作小部件的页面：

选项1（广义，更侧重于用户会做什么）

class WidgetPage

   def click_widgets_tab
        click_on('Widgets')
    end

    def create_widget_button
        click_on('Add Widget')
    end

    def enter_widget_name(name)
        fill_in 'Widget Name', with: name
    end

    def enter_widget_type(type)
        fill_in 'Widget Type', with: type
    end

    def widget_success?
        expect(page).to have_content('.alert', text: 'Widget Successfully created!')
    end
end

（在上述情况下，“填充”方法可能甚至可以合并

或选项2：

class WidgetPage

    def click_widgets_tab
        widget_tab_link.click
    end

    def create_widget_button
        widget_add_element.click
    end

    def enter_widget_name(name)
        widget_form_name.fill_in(name)
    end

    def enter_widget_type(type)
        widget_form_type.fill_in(type)
    end

    def widget_success?
        widget_success_alert.has_text? 'Widget successfully created!'
    end


    private

    def widget_add_element
        find_button('Widget')
    end

    def widget_form_name
        find_field('Widget Name')
    end

    def widget_form_type
        find_field('Widget Type')
    end

    def widget_tab_link
        find_link('Widgets')
    end

    def widget_success_alert
        find(.alert, text: "Widget successfully created!")
    end

end

我觉得我看到大多数页面对象教程都使用选项2 ......但它似乎有很多额外的代码，几乎没有投资回报。如果在多种方法中使用返回元素的方法对我有意义......但不适用于每种方法。

另外，就断言而言，选项1更有意义。但我也听说你不应该在页面对象中有断言。所以也许让一个方法返回一个例如是否可见的警报更有意义？仍然不确定处理它的最佳方法。

Answer 1

我认为这是一个公平的问题，很多问题都归结为偏好，但如果你为自己的情况选择了错误的“偏好”，你可能会遇到一些非常严重的陷阱，所以我认为值得讨论。

• 部分意见：如果您的应用程序存在片状/易变/易于需要解决方法，请在页面对象中考虑更细粒度的方法，并在步骤定义中考虑更少的Capybara。在步骤defs中有几十个page.element.click()调用非常烦人，所有这些都需要更新，因为应用程序更改为每次点击前需要悬停。如果该操作作为page.clickElement()包装在页面对象中，那么您只有一个地方可以进行更新（或实现变通方法）。
• 大多数意见：如果你完全包装Capybara可以为每个元素做的一切，你最终会得到一个难以使用的膨胀的页面对象。如果有一组步骤defs将在90％的时间内使用，我会将它们公开为显式方法，并让其余10％边缘大小写类型的动作直接使用这些元素。
• 部分意见：请注意，capybara的click_on / fill_in方法限制您使用他们的定位器概念（名称，ID或标签）。我总是发现这与任意CSS相比都是如此限制，我避免使用它们。
• 较少的意见：避免在页面对象中放置断言！页面对象是页面的抽象，而不是业务规则的测试。对于上面的示例，两个选项都将失败，并显示“找不到元素”或“false！= true”，这不是很有用。考虑从页面对象返回文本（不管它是什么），并在步骤def中断言。

就像是

def get_widget_alert
    find(.alert).get_text()
end

从步骤def调用为

expect(widget_page.get_widget_alert).to eq('Widget Successfully created!')

如果有人决定在路上更改标点符号或邮件的情况，将会失败并显示有用的消息。