2

このような長いチェーンを持ち、Then / Whenが混ざり合うユーザーストーリー/受け入れテストをどのように処理しますか？これを別の受け入れテストに分割して、1つはダイアログが表示されることをテストし、もう1つはダイアログが表示された後の動作をテストするのが最善ですか？

Feature: Confirmation before removing products from cart
  In order to avoid accidentally removing an item from my cart
  As a Customer
  I want a confirmation dialog to ask me if I'm sure I want to remove an item

  Scenario: I want to remove an item from my cart
    Given I have added item "xyz" to my cart
    When I click "Remove"
    Then a confirmation dialog pops up
    And it asks "Are you sure you want to remove this from your cart"
    When I click "Yes"
    Then item "xyz" should be removed from my cart
4

2 に答える 2

2

あなたのシナリオは少し長いように見えます、そしてそれはGUIにかなり強く結びついています。代わりにそれをシステムの機能に結び付けたらどうなるでしょうか？

Scenario: I want to remove an item from my cart
  Given I have a cart containing "xyz"
  When I remove "xyz" from my cart
  Then my cart should be empty.

シナリオでは、ユーザーにとって有用なものについて説明し、リファクタリングが簡単になりました。

私はこのような状況にあったので、私と同じようにBDDが大好きです。120の受け入れテストがあり、ほとんど失敗していました。誰かがあなたが説明したものとよく似た確認ダイアログボックスを配置し、80を超える受け入れテストを即座に破りました。代わりに、それらを高レベルで再利用可能な手順のシナリオに変換することで、システムの機能を実装するために使用するメカニズムが変更された場合でも、テストを簡単にリファクタリングして機能させ続けることができます。ボタンの実際のクリックは、これらの再利用可能なステップ内で発生し、ステップごとに複数のUIアクションがあっても問題ありません。

私はここで、それが有用である場合にこれを行うシナリオを作成しました（英語ではなくDSLですが、アイデアを得る必要があります）。

http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs

于 2010-08-18T23:40:48.850 に答える
1

問題は、実際には「ブランチ」とは何かの1つです。

複数のステップがある場合は、各ステップでユーザーが選択する必要があります。複数の「いつ」があるはずです。これにより、各ブランチでユーザーが選択した多数の選択肢を含む豊富なツリーが形成されます。それぞれの可能な結果には、さまざまな選択を行い、その結果に到達するための独自のテストが必要です。

2つのユーザーが選択できる3つのステップのシーケンスは、8つの可能なパスです。異なるパスが同じ結果に到達する場合があります（または到達しない場合があります）。ただし、これには複数のパスが必要です。

それが単にシーケンシャルであり（誰かがシーケンシャルなステップを書きたいと感じたため）、ユーザーに選択肢がない場合、それは実際にはユーザーの行動を考慮したものではありませんか？

選択肢がわかりません。選択肢なし==悪臭。しかし、ユーザーが選択肢をほとんどまたはまったく持たない一連のキャプティブステップの結果は1つしかないため、テストは簡単です。

選択を適切に行う場合、各ステップには複数の結果があり、各ステップは個別にテストする必要があります。

于 2010-08-18T22:47:20.677 に答える