1

彼の記事What's in a Story? で ダン・ノースは多くの優れた点を挙げています。特に次の 3 つです。

  1. シナリオのタイトルは、何が違うのかを示す必要があります

    シナリオを並べて並べ、タイトルのみを使用してそれらの違いを説明できる必要があります。

  2. シナリオは、ギブンス、イベント、および結果の観点から説明する必要があります

    これは、BDD を採用しているチームで私が見た最も強力な行動の変化です。ビジネス ユーザー、アナリスト、テスター、および開発者に、この「与えられた/いつ/その時」という語彙を採用させるだけで、あいまいな世界がなくなることがわかります。

    すべてのシナリオがこれほど単純なわけではありません。いくつかは一連の出来事として表現するのが最もよく、次のように表現されます: [ある文脈] が与えられたとき [私が何かをする] のとき [これが起こる] [私が別のことをする] のとき [この新しいことが起こる]など。例として、一連の画面をステップ実行して複雑なデータ モデルを構築するウィザード スタイルの Web サイトがあります。これらの用語で考える習慣を身につけている限り、一連の出来事と結果を混ぜ合わせることは完全に適切です.

  3. ストーリーは、イテレーションに収まる程度に小さくする必要があります

    実証可能なチャンクに分割する限り、これを行う方法について厳格な規則はありません。一般に、シナリオが 5 つまたは 6 つ以上ある場合は、同様のシナリオをグループ化することで、ストーリーを分割できる可能性があります。

ここで、あるウィザード スタイルの機能のエンド ツー エンドの受け入れテストを記述しようとしているとします (上記で検討したように)。

  • ウィザード機能の使用開始時に状態がどのように異なるかによって「シナリオ」を定義するのは当然のことです (実際、これは上記のポイント 1 と 2 に適合するように思われます)。そのような独立したシナリオを作成するために、完全にシリアル化された形式で (最初から最後まで)? これにより、非常に多くのシナリオが生成されるだけでなく、それぞれが非常に多くのステップで構成されます (Dan のポイント 3 に反して)。これらのステップの多くは、シナリオが分岐する状態に到達するためだけにシナリオ間で繰り返されます。

    Scenario: Make a successful booking
  Given that I am at the booking form
  When I do A
  Then I see B
  When I do C
  Then I see D
  When I try to book
  Then I see a successful message

Scenario: Attempt to book, no availability
  Given that I am at the booking form
  When I do A
  Then I see B
  When I do C
  Then I see D
  When I try to book
  Then I see no availability

  • 一方、ウィザード機能内の各決定分岐の開始時に、考えられる状態ごとに1 つのシナリオを定義する方が効率的です。 「イベント」は、単に機能を次のステップに進める単一のステップになります。決定分岐。しかし、これは SUT をスタックの下に移動しないので、エンドツーエンドの受け入れテストを定義するのではなく、より低い順序のものを定義することになりますか? さらに、テスト基準に従って理解することは、はるかに自然なことではありません。これは、BDD の要点全体を確実に無効にしますか?When

    Scenario: Do first step
  Given that I am at the booking form
  When I do A
  Then I see B

Scenario: Do second step
  Given that I see B
  When I do C
  Then I see D

Scenario: Make a successful booking
  Given that I see D
  When I try to book
  Then I see a successful message

Scenario: Attempt to book, no availability
  Given that I see D
  When I try to book
  Then I see no availability

    このルートに進む場合、各決定ブランチを個別の機能に分割する方が正しいように思えます。そして、各ブランチのシナリオのみが 1 つの機能内で考慮されます。これは、SUT がスタックを下に移動したという私の主張を強調するだけです。

  • おそらく、これらのエンド ツー エンドの受け入れテストは詳細すぎるため、ウィザード全体を (この段階では) ブラック ボックスとして扱う必要がありますか? ただし、これが顧客が何を試運転しているのかを理解するのにどのように役立つかはわかりません。特に、この機能の詳細な手順がシステム全体の受け入れ可能性の鍵となるためです。

そのような機能をシナリオに分割する最も適切な方法は何ですか?

4

2 に答える 2

2

私たちのほとんどがウィザードに関して抱えている問題は、物事を表現する方法に関係しています。ある機能が何かが「どのように」行われるかを調査すると、冗長になってしまいます。私たちが集中すべきことは、なぜ私たちは物事を行っているのかということです。

このように考えると、ウィザード全体を 1 つのものとしてカプセル化することで、問題を完全に無効にすることができます。例えば：

Feature: Fill in my tax form

Scenario: Fill in my tax form
  When I fill in my tax form
  Then my tax form should be filled in

ただし、これはおそらく、これほど複雑なものの抽象化を「高く」することです。詳細を追加するには、シナリオを部分に分割し、各部分に記入する理由を見つける必要があります。次に、その理由 (why) を使用してシナリオを記述します。

納税申告書に戻って、(簡単にするために) ID、収入、経費の 3 つの部分だけが含まれているとします。

これで、次のように記述できます。

Feature: Tax indentification
  As someoene who is taxed
  I need to provide proper indentification
  So I pay for my tax and not someone else's

Scenario: Provide indentification
  Given I am filling in my tax form
  When I provide indentification
  Then I should be asked about my income

次のようなもので悲しい道を探索できます

  When I provide insufficient identification
  Then I should be asked for more indentification

等

実装したら、書くことができるはずです

Feature: Tax - provide income details
  ... 

Given I am filling in my tax form
And I have provided indentification
When I provide my income details
Then I should be asked about my expenses

悲しい道を探索するプロセスを繰り返すことができます。アイデンティティ ステージの実装時に作成したテスト機能を使用して、Given を実装できることに注意してください。

これの芸術は、プロセスの各段階を完了する理由と、プロセスを旅するときに到達するさまざまな状態にどのような名前を付けるかを見つけることです. また、この機能のどこにも「どのように」これを行うかについての言及がないことに注意してください

最後に、これはあなたが話した 2 番目の方法であり、「どのように」よりも「なぜ」に重点が置かれています。抽象化のレベル (つまり、これをいくつの部分に分割するか) を選択でき、命名を制御できます。言語と命名は、読みやすさの問題に対処します。特に、機能の名前やファイル階層内での位置などから与えることができる追加のコンテキストを考慮に入れる場合はそうです。

于 2015-05-10T17:09:53.537 に答える