23

典型的な CRUD シナリオを定義するときに、テスト データを指定するための 2 つのオプションがあることに気付きました。

オプション 1: 使用するデータを記述し、実装にデータを定義させる

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have typed in a valid name
      And I have typed in a valid code
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the created region details

オプション 2: 使用するテスト データを明示的に述べる

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have filled out the form as follows
        | Label | Value  |
        | Name  | Europe |
        | Code  | EUR    |
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the following fields
        | Name   | Code |
        | Europe | EUR  |

利点と欠点に関して、私たちが確立したことは次のとおりです。

オプション 1 は、「有効な名前」の定義が変更された場合を適切にカバーします。テスト データが複数の場所にあるオプション 2 を使用した場合、これに対処するのがより困難になる可能性があります。オプション 1 は、特に「無効なクレジット カード番号を入力した」などのシナリオの場合に、このテストのデータで何が重要かを明示的に説明します。また、実装よりも説明に関心があり、どういうわけかより抽象的でBDDを「感じ」ます。

ただし、オプション 1 では、再利用が難しい非常に特殊な手順を使用します。たとえば、「作成されたリージョンの詳細をページに表示する必要があります」は、おそらくこのシナリオでのみ使用されます。逆に、オプション 2 の「ページには次のフィールドを表示する必要があります」を実装して、他のシナリオで何度も再利用できるようにすることもできます。

また、オプション 2 は、「有効」などのより抽象的な用語を解釈する必要がなく、例によって何が起こっているかを確認できるため、よりクライアントフレンドリーに見えると思います。ただし、オプション 2 はより脆弱でしょうか? モデルのリファクタリングは、これらのテストを中断することを意味する場合がありますが、テスト データがコードで定義されている場合、コンパイラはモデルの変更に役立ちます。

ここに正解も不正解もありませんが、どちらを使用するかをどのように決定するかについて、人々の意見を聞きたいと思います。

ありがとう！

4

4 に答える 4

11

状況次第だと思います。シナリオを正常に実行するには、大量のデータが必要になる場合があります。多くの場合、そのデータの大部分は、実際にテストしているものにとって重要ではないため、シナリオで達成しようとしている理解から気を散らすノイズになります。シナリオに固有のデータとマージできるデフォルトデータを提供するために、デフォルトデータパターンと呼ばれるものを使い始めました。私はそれについてここに書いた：

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

これがお役に立てば幸いです。

于 2011-01-15T17:31:03.957 に答える
4

私はオプション2を好みます。

ビジネス ユーザーには、入力と出力が何であるかがすぐにわかります。オプション 1 では、有効なデータが何であるかがわからないため、実装が間違っている可能性があります。

必要に応じて、無効なデータも追加することで、さらに表現力を高めることができます

Scenario: Filter for Awesome
    Given I have navigated to the "Show People" page
    And I have the following data
    | Name  | Value  |
    |  John | Awesome|
    |  Bob  | OK     |
    |  Jane | Fail   |
When I click the "Filter" button
Then the list should display    
    | Name   | Value   |
    |  John  | Awesome |

ただし、特定の実装ではなく、ドメインの観点から記述されるようにデータを保持する必要があります。これにより、アプリケーションのさまざまなレイヤーでテストできます。例：UI サービスなど

于 2011-01-12T21:02:34.100 に答える
2

これについて考えるたびに、私は考えを変えます。しかし、よく考えてみると、テストはリージョンを作成できることを証明することです。両方のオプションが満たす基準。しかし、オプション 2 の視覚的な合図と開発者の使いやすさは、断るにはおそらく良すぎることに同意します。このような例では、少なくとも。

于 2011-01-13T21:27:20.267 に答える
0

一歩下がって、これらのシナリオで説明しようとしているストーリーやルールを尋ねることをお勧めします。有効または無効な地域コードを作成するルールがあり、利害関係者が BDD を使用して説明したい場合は、有効な地域コードと無効な地域コードの具体例を使用できます。領域が作成された後に何が起こるかを説明したい場合、正確なデータはそれほど興味深いものではありません。

あなたの「リージョンの作成」は、BDD で使用する典型的なシナリオではありません。それは「私がものを作るとき、私はそのものを見ることができる」と特徴付けることができます. それ自体ではユーザーに価値のあるものを提供しないという点で、これは有用なシナリオではありません。興味深いものや価値のあるものがエンドユーザーに届けられるシナリオを探します。ユーザーがリージョンを作成するのはなぜですか? 最終目標は何ですか？別のユーザーが他のオブジェクトをその領域に割り当てることができるようにするためでしょうか?

ストーリーがルールと例にリンクされている (例がシナリオになる) サンプル マッピングは、https://cucumber.io/blog/bdd/example-mapping-introduction/で説明されています。

于 2021-03-10T08:38:26.150 に答える