7

ドキュメント セットのナビゲーションを表示し、それらのドキュメントのさまざまなメタデータを公開する Web アプリ用のモーダル スライドショーを作成しました。

これは、難解な要件を持つアプリケーションの大きなコンポーネントであるため、そのコア シナリオ (受け入れ基準として私に与えられたもの) が多数ありながら内部的に一貫していなければならないことは十分に公平だと思います。

多くのシナリオごとに新しいステップが必要になるのを避けるために、次のような人間が読める用語をセレクターに変換するヘルパーを採用しました。document caption

module SelectorsHelper
  def selector_for(term)
    case term
    # Lightbox / modal / fancybox
    when 'lightbox'
        '#fancybox-inner'
    when 'close button'
        '.document-viewer__tools__close'

…次のようないくつかの一般的なステップ定義とともに:

# Generic click action
When(/^I click (?:on )?(?:the |a )'(.*?)'?$/) do |element|
  find(selector_for(element)).click
end

問題は、私が上記のような非常に一般的な概念に基づいて行動しているか、一連の機能内で繰り返されるパターンを含むより具体的な抽象化に基づいて行動しているかにかかわらず、これらが他の難解な機能に大混乱をもたらす可能性があることです。彼ら。私が見たすべての Cucumber の例には、ファイル名が特定の機能ファイルとの手続き上の関係を持つステップ定義ファイルがあり、これらの場合、そのステップ定義ファイルは関連する機能のシナリオを解析するためにのみ呼び出されると仮定しました。

+ features
| + step_definitions
| | + global_steps.rb
| | + modal_steps.rb
| | + login_steps.rb
| + modal.feature
| + login.feature

しかし、そうではありません。私は、Cucumber がすべてのステップ定義パターンをすべてのシナリオに適用しようとしているという考えに甘んじるのに苦労しています。これらのテストにメリットがあるとすれば、テストの数が増え、新しい概念が導入され、継続的に書き直すことなく関連性が維持されます。ステップの範囲を制限して、作成されていない機能に干渉しないようにしたいのですが、方法がわかりません。次の概念的な解決策が思い浮かびます。

  • バックグラウンドまたはシナリオを使用@tagsし、それらのタグを持つシナリオに対してのみステップを呼び出す
  • 特定の誤った背景によって呼び出されるある種のラッピング ヘルパーまたはメタステップ定義でステップ定義をネストする

私はRubyに不慣れで、Cucumberは非常に薄いように見えるので、一方で無限の可能性と、他方で事前に決定された実装がないことに気が遠くなります。何か案は？

4

1 に答える 1