18

うまくいけば、他の人が理解できるように自分の問題を十分に明確に説明できます。ここで、次の2つの仮想シナリオがあると想像してください。

Scenario: Filter sweets by king size and nut content
Given I am on the "Sweet/List" Page
When I filter sweets by 
    | Field               | Value  |
    | Filter.KingSize     | True   |
    | Filter.ContainsNuts | False  |
Then I should see :
    | Value            |
    | Yorkie King Size |
    | Mars King Size   |

Scenario: Filter sweets by make
Given I am on the "Sweet/List" Page
When I filter sweets by 
    | Field        | Value  |
    | Filter.Make  | Haribo |
Then I should see :
    | Value   |
    | Starmix |

これらのシナリオは、関連するコンパイル済みテストステップを変更せずに、フィールド/値およびThenValueエントリのWhen行を好きなだけ追加できるので便利です。ただし、さまざまなフィルターテストのコピー/貼り付けのシナリオは繰り返しになり、多くのコードを使用することになります。これは避けたいことです。理想的には、シナリオのアウトラインを作成し、上記のテストでの動的な性質を維持したいと思いますが、それを実行しようとすると、サンプルテーブルの定義で問題が発生し、適切と思われる新しい行を追加できません。新しいテストインスタンス、現在私はこれを持っています：

Scenario Outline: Filter Sweets 
Given I am on the <page> Page
When I filter chocolates by 
    | Field    | Value   |
    | <filter> | <value> |
Then I should see :
    | Output   |
    | <output> |
Examples:
    | page       | filter      | value  | output  |
    | Sweet/List | Filter.Make | Haribo | Starmix |

したがって、シナリオのアウトラインを使用すると、フィルターと期待されるデータに行を動的に追加できるという問題があります。これを回避する方法を知っている人はいますか？別の角度からこれにアプローチする必要がありますか？

回避策は次のようになります。

Then I should see :
    | Output |
    | <x>    |
    | <y>    |
    | <z>    |
    Examples:
    | x | y | z |

しかし、それはあまり動的ではありません....より良い解決策を望んでいますか？:)

4

2 に答える 2

36

SpecFlow、Gherkin、およびすぐに使用できるCucumberでは、あなたが求めていることは不可能だと思います。著者のことを話すことはできませんが、これらの仕様を作成して実装する全体的な「流れ」に反するため、意図的にこのように使用することを意図したものではないに違いありません。とりわけ、仕様は、プログラマー以外の人にも読めるように、仕様に一致するコードを実装するためのガイドをプログラマーに提供し、統合テストを行い、リファクタリング時に証明書にある程度の柔軟性を与えることを目的としています。

これは、あなたが感じている痛みが問題の兆候である状況の1つだと思いますが、それはあなたが思っているものではないかもしれません。あなたが言った：

「しかし、さまざまなフィルターテストのコピー/貼り付けのシナリオは繰り返しになり、多くのコードを使用することになります。これは避けたいことです。」

まず、書面で自分自身を説明することが「反復的」であることに同意しません。少なくとも、「the、apple、carなど」などの特定の単語を使用することは反復的です。何度も何度も。問題は次のとおりです。これらの言葉はあなたがしていることを適切に説明していますか？もしそうなら、そしてあなたの状況を説明するためにあなたが複数のシナリオを書き出す必要があるなら、それはまさにそれが必要とするものです。コミュニケーションには言葉が必要であり、時には同じ言葉が必要です。

実際、「反復的」と呼ぶものは、GherkinとCucumberやSpecFlowなどのツールを使用する利点の1つです。その文を何度も何度も使用できる場合は、テストコードを何度も何度も書く必要がないことを意味します。

第二に、あなたは正しいことのためのスペックを書いていると確信していますか？シナリオの数が手に負えなくなって、人間があなたの書いたものを追うことができないほど多くなると、あなたのスペックが正しいものに向けられていない可能性があるからです。

この可能性のある例は、このシナリオでフィルタリングとページネーションをテストする方法です。はい、あなたはあなたのスペックが完全な機能をカバーすることを望みます、そしてあなたのサイトはあなたのフィルタリングと同じページにページ付けをします、しかしどのくらいの費用がかかりますか？想定される「理想的な」モックなしの完全統合テストをあきらめると、より良い結果が得られることを知るには、経験と実践が必要です。

第三に、スペックがすべての可能なシナリオを完全にカバーすることを意図しているとは思わないでください。シナリオは基本的に状態のスナップショットです。つまり、無限に大きなシナリオのセットをカバーできる機能がいくつかありますが、これは不可能です。それで、あなたは何をしますか？ストーリーをできる限り伝える機能を作成します。物語が開発を推進するようにさえしましょう。ただし、仕様やその他のケースに変換されない詳細は、仕様に加えて行われる、まっすぐなTDDに任せるのが最善です。

あなたの例では、基本的に、ユーザーがお菓子やキャンディーに対して動的な検索を作成できるサイトについての話をしているようです。可能な検索条件の大規模なセットの1つを入力し、ボタンをクリックして、結果を取得します。ストーリーを実現するのに十分なスペックだけを書いて、それに固執してください。カバレッジに満足できない場合は、より多くの仕様または単体テストでクリーンアップしてください。

とにかく、それは私の考えです、それが役立つことを願っています。

于 2011-02-27T03:11:06.323 に答える
8

技術的には、ステップ定義内からステップを呼び出すことができると思います。

ステップ定義からのステップの呼び出し

たとえば、私はあなたが書き直すことができると思います

Then I should see :
| Output   |
| <output> |

のようなカスタムステップになる

I should have output that contains <output>

ここで、outputは、期待値のコンマ区切りのリストです。カスタムステップでは、コンマ区切りのリストを配列に分割し、それを繰り返して呼び出すことができます。

Then "I should see #{iterated_value}"

同様の手法を使用して、フィルターとフィルター値のリストを渡すことができます。キングサイズテストの行の例は次のようになります。

| page       | filter                               | value       | output                           |
| Sweet/List | Filter.KingSize, Filter.ContainsNuts | True, False | Yorkie King Size, Mars King Size |

または多分

| page       |                              filter-value-pairs | output                           |
| Sweet/List | Filter.KingSize:True, Filter.ContainsNuts:False | Yorkie King Size, Mars King Size |

そうは言っても、あなたはおそらくダレンの言葉を心に留めるべきです。この方法が、開発者以外の人が読めるシナリオを作成するという最終的な目標に役立つかどうかはわかりません。

于 2011-02-27T04:27:17.313 に答える