Behavior-driven-development-tdd-in-a-bdd-way
BDD-BDD方式のTDD
TDDでは、「受け入れテスト」という用語は誤解を招くものです。 受け入れテストは、実際にシステムの予想される動作を表します。 アジャイルプラクティスでは、チーム全体のコラボレーションと、顧客や他の利害関係者との相互作用が強調されています。 これにより、プロジェクトに関わるすべての人が容易に理解できる用語を使用する必要性が生じています。
TDDを使用すると、必要な*動作*について考えることができるため、「動作」という用語は「テスト」という用語よりも便利です。 BDDはテスト駆動開発であり、テストではなく動作に焦点を当てた語彙を備えています。
ダンノースの言葉を借りると、「テストでの思考から行動での思考への移行が非常に深いため、TDDをBDD、または行動駆動型開発と呼ぶようになりました。」TDDは何かの仕組みに焦点を当てています。構築します。
BDDは、開発者がよく直面する次の質問に答えます-
| Question | Answer |
|---|---|
| Where to start? | outside-in |
| What to test? | User Stories |
| What not to test? | anything else |
これらの回答により、ストーリーフレームワークは次のようになります-
ストーリーフレームワーク
*[役割]*欲しい [機能]
*[ベネフィット]*これは、「*機能*が実行されると、結果として得られる*利益*は*役割を演じる人*になります」という意味です。
BDDはさらに次の質問に答えます-
| Question | Answer |
|---|---|
| How much to test in one go? | very little-focused |
| What to call their tests? | sentence template |
| How to understand why a test fails | documentation |
これらの答えは、次の例のフレームワークになります-
フレームワークの例
初期コンテキストを与えて、
- イベント*が発生したとき、
- そして*いくつかの結果を保証します。
これは、「特定のイベントが発生したときに、初期コンテキストから始めて、結果がどうあるべきかを知っている」ことを意味します。
したがって、この例はシステムの予想される動作を示しています。 例は、システムのさまざまなシナリオを説明するために使用されます。
ストーリーとシナリオ
ATMシステムに関するDan Northの次の図を考えてみましょう。
ストーリー
- 顧客*として、
私はATMから現金を引き出したい
- そう*私は銀行で並んで待つ必要はありません。
シナリオ
このストーリーには2つのシナリオが考えられます。
- シナリオ1 *-アカウントにクレジットがあります
アカウントにクレジットが付与されている
- そして*カードは有効です
- そして*ディスペンサーには現金が含まれています
- いつ*顧客が現金を要求する
- その後*口座から引き落とされることを確認する
- そして*現金が確実に分配される
- そして*カードが返されることを確認する
- シナリオ2 *-アカウントは当座貸越限度を超えて引き落とされます
- 与えられた*アカウントが引き落とされた
- そして*カードは有効です
- いつ*顧客が現金を要求する
- その後*拒否メッセージが表示されることを確認します
- そして*現金が出されないようにする
- そして*カードが返されることを確認する
イベントは両方のシナリオで同じですが、コンテキストは異なります。 したがって、結果は異なります。
開発サイクル
BDDの開発サイクルは、外部からのアプローチです。
- ステップ1 *-赤になる高レベル（外部）のビジネス価値の例（CucumberまたはRSpec/Capybaraを使用）を記述します。 （RSpecはRuby言語でBDDフレームワークを生成します）
- ステップ2 *-実装の最初のステップである赤の下位レベル（内部）RSpecの例を記述します。
- ステップ3 *-その下位レベルの例を渡すための最小限のコードを実装し、緑色になることを確認します。
- ステップ4 *-次の低レベルのRSpecの例を書いて、赤になるステップ1をパスするように押します。
- ステップ5 *-ステップ1の高レベルの例が緑色になるまで、ステップ3とステップ4を繰り返します。
注-次の点に留意してください-
- *赤/緑*状態は許可ステータスです。
- 低レベルのテストが緑色の場合、新しいサンプルを作成したり、既存の実装をリファクタリングしたりできます。 リファクタリングのコンテキストでは、新しい機能/柔軟性を追加しないでください。
- 低レベルのテストが赤の場合、既存のテストを緑にするためにのみ実装コードを作成または変更する権限があります。 存在しない次のテストに合格するコードを記述する衝動に抵抗する必要があります。または、良いと思われる機能を実装する必要があります（顧客は尋ねなかったでしょう）。
