Capybaraを直接使用するのではなく、ページオブジェクトモデル（例：SitePrism）でラジオボタンを定義する利点はありますか？

Question

私はcucumber/ruby​​/capybara/siteprismフレームワークを使用しており、現在テストページを実装していました。私はいくつかのページに1ページあたり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 

は、私は1つのすべてのボタンに配列して「要素」または「セクション」を作成ことができると思いますが、その後、私たちはそれらを解析し、とにかくどこかに関連するいずれかをクリックして、余分なロジックを配置する必要がありますコードでは、それはすべてき​​ちんと行われ、余分なコードやcapybaraの '選択'メソッドでメンテナンスする必要はありませんでした。

この例では、Capybaraを使用する方が良い選択肢だと思いますか？ ページオブジェクトモデルで 'ALL'ウェブ要素を定義する方がよい場合は、そのメリットは何ですか？可能性のあるメリットを生かすためにページオブジェクトコードを別の方法で行うことができますか？

PS：だけでなく、私は概念的にテストの構造が類似していることを推測すると「ページ・オブジェクト」、「ワチール」のタグを追加すると、ので、多分そのフレームワークを使用して、誰かが助けることができるだけでなく...

Answer 1

このような複雑なケースのステートメントは不要です。

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

私はsite_prismに精通していません。ページオブジェクトにこの方法で

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

：マイwatir_drops宝石は、あなたがこのような同じパターンですべてを定義できます

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

我々はまた、代わりに、宣言を使用しての全体の長い議論に入ることができ命令的なステップのまた、ベスト・プラクティス・ページ・オブジェクトの使用法では、定義さビジネスロジックを達成するメソッドを呼び出すと、それらのメソッドは、要素定義やアクションを含むすべての実装を行います。