在页面对象模型（例如 SitePrism）中定义单选按钮而不是直接使用 Capybara 有什么好处吗？答案

【问题标题】：Is there any benefit of defining radio buttons in a Page Object model (eg. SitePrism) rather than using Capybara directly?在页面对象模型（例如 SitePrism）中定义单选按钮而不是直接使用 Capybara 有什么好处吗？
【发布时间】：2016-12-02 00:48:45
【问题描述】：

我目前正在使用 cucumber/ruby/capybara/siteprism 框架并实现测试页面。我已经到了这样一个地步，即在几个页面中每页有很多单选按钮（超过 20 个），我在想，尝试将所有这些单选按钮映射为我的页面对象模型中的静态元素是否真的有任何好处？

也就是说，想一想，在步骤定义中直接使用单选按钮的文本并直接调用capybara的'choose'方法似乎更方便，如下所示，这样我就不需要了为这 20 多个单选按钮做任何其他事情，它都应该通过更改我们在功能中传递的参数来工作：

cucumber feature:
  When I select that "I am over 18"

capybara step:
  When /^I select that "(.*)"$/ |option|
      choose(option)

而对于像 siteprism 这样的页面对象模型，我猜想实现需要以类似于以下的格式独立定义和维护所有这些元素：

element :over_18_button, :radio_button, "I am over 18"
element :over_12_button, :radio_button, "I am over 12"
etc x50times

为了使用它，应该创建页面，调用元素，这对我来说似乎不那么直接？

siteprism step:
  When /^I select that "(.*)"$/ |option|
     case option
        when 'I am over 18'
           over_18_button.click
        when 'I am over 12'
           over_12_button.click

我想可以为所有按钮创建一个带有数组的“元素”或“部分”，但是，我们必须添加额外的逻辑来解析它们并在代码中的某个地方点击相关的，而使用 capybara 的“选择”方法，这一切都可以顺利完成，无需任何额外的代码或维护。

我是否认为在这个例子中使用 Capybara 是一个更好的选择？或者如果在页面对象模型中定义“所有”网络元素会更好，这样做有什么好处？页面对象代码能否以不同的方式完成以利用任何可能的好处？

【问题讨论】：

标签： ruby capybara pageobjects site-prism

【解决方案1】：

那种复杂的case语句是不必要的。

  When /^I select that I am over "(\d\d)"$/ |age|
   @page_object.select_age(age)

我不熟悉 site_prism。我的 Watir_drops gem 可以让你用相同的模式定义所有东西：

element(:age_button) { |age| browser.radio_button(text: "I am over #{age}")

在页面对象中使用此方法：

def select_age(age)
  age_button(age).set
end

我们还可以就使用声明式步骤而不是命令式步骤进行长时间的讨论。此外，最佳实践页面对象使用避免直接调用定义的元素。调用完成业务逻辑的方法，这些方法完成所有的实现，包括元素定义和对它们的操作。

【讨论】：

我明白你的意思，有一个函数可以获取参数并在定义页面对象元素时传递它......但在这种情况下，使用'@page_object.select_age（ age)' 使用新的实现（加上需要创建新函数和定义元素），而不是直接使用 capybara 或 watir 方式 - 比如 'choose(age)' 并避免所有其他位？我不明白为什么这是个好主意，但我可能错过了页面对象模型中的一个重要点？
页面对象模式解决了几个问题。 1）从业务逻辑中抽象出实现逻辑（what vs how）2）保持代码DRY（所有东西都可以在一个地方更新）和3）智能组织更容易维护（当页面发生变化时，你更新一个相关的页面目的）。我无法谈论 Capybara 的最佳实践，但 Watir 更像是一个库（对于 Capybara 的框架），它非常适合这种抽象。

【解决方案2】：

老问题，但添加了重要的缺失信息

site_prism 的工作方式允许您使用可在 Capybara 中查询的任何内容来定义选择器。因此，如果您想使用文本定义您的收音机，您可以这样做。或您想使用的任何其他定位策略。

显然，传统上我建议使用 css 定位器（ element :my_radio, text: 'foo')，因为它们最容易调试和重用。此外，OP 建议他有 50 多个。如果它们相同，则可以将它们抽象为 Helper Module，或者他甚至可以使用循环和索引对它们进行元编程（如果它们遵循简单的 index_naming_pattern）

【讨论】：