BDD-BDD方式のTDD
TDDでは、「受け入れテスト」という用語は誤解を招く恐れがあります。受け入れテストは、実際にはシステムの予想される動作を表します。アジャイルプラクティスでは、チーム全体のコラボレーションと、顧客やその他の利害関係者とのやり取りが強調されます。そのため、プロジェクトに関わっているすべての人が理解しやすい用語を使用する必要が生じています。
TDDはあなたに必要なことを考えさせます Behavior したがって、「行動」という用語は、「行動」という用語よりも有用です。 ‘Test’。BDDは、テストではなく動作に焦点を当てた語彙を備えたテスト駆動開発です。
ダン・ノースの言葉によれば、「テストでの思考から行動での思考への移行が非常に深かったので、TDDをBDDまたはビヘイビア駆動開発と呼び始めました。」TDDは何かがどのように機能するかに焦点を合わせ、BDDはなぜそれを構築するのかに焦点を合わせます。
BDDは、開発者がよく直面する次の質問に答えます-
| 質問 | 回答 |
|---|---|
| どこから始めれば？ | 外で |
| 何をテストしますか？ | ユーザーストーリー |
| 何をテストしないのですか？ | 他に何か |
これらの答えは、次のようなストーリーフレームワークになります-
Story Framework
として [Role]
が欲しいです [Feature]
そのため [Benefit]
これは、 ' Feature 実行され、結果 Benefit 演奏する人に Role.'
BDDはさらに次の質問に答えます-
| 質問 | 回答 |
|---|---|
| 一度にいくらテストしますか？ | あまり焦点を当てていない |
| 彼らのテストを何と呼びますか？ | 文テンプレート |
| テストが失敗する理由を理解する方法 | ドキュメンテーション |
これらの回答により、次のようなサンプルフレームワークが作成されます。
Example Framework
Given いくつかの初期コンテキスト、
When イベントが発生し、
Then いくつかの結果を確認します。
つまり、 '最初のコンテキストから始めて、特定のイベントが発生すると、結果がどうなるかがわかります。 should be。」
したがって、この例は、システムの予想される動作を示しています。例は、システムのさまざまなシナリオを説明するために使用されます。
ストーリーとシナリオ
次のDanNorthによるATMシステムに関する図を考えてみましょう。
物語
As a お客様、
I want ATMから現金を引き出すには、
so that 銀行に並んで待つ必要はありません。
シナリオ
このストーリーには2つのシナリオが考えられます。
Scenario 1 −アカウントはクレジットされています
Given アカウントはクレジットされています
And カードは有効です
And ディスペンサーには現金が含まれています
When 顧客が現金を要求する
Then アカウントから引き落とされていることを確認します
And 現金が確実に分配されるようにする
And カードが返却されていることを確認してください
Scenario 2 −当座貸越限度額を超えて口座が引き落とされた
Given アカウントが引き落とされている
And カードは有効です
When 顧客が現金を要求する
Then 拒否メッセージが表示されていることを確認します
And 現金が支払われないようにする
And カードが返却されていることを確認してください
イベントは両方のシナリオで同じですが、コンテキストが異なります。したがって、結果は異なります。
開発サイクル
BDDの開発サイクルは outside-in アプローチ。
Step 1−赤くなる高レベル（外部）のビジネス価値の例（CucumberまたはRSpec / Capybaraを使用）を記述します。（RSpecはRuby言語でBDDフレームワークを生成します）
Step 2 −赤くなる実装の最初のステップのための低レベル（内部）のRSpecの例を書いてください。
Step 3 −その下位レベルの例を渡すための最小限のコードを実装します。緑色になるのを確認してください。
Step 4 −赤くなるステップ1の通過に向けてプッシュする次の下位レベルのRSpecの例を記述します。
Step 5 −ステップ1の高レベルの例が緑色になるまで、ステップ3とステップ4を繰り返します。
Note −以下の点に注意してください−
Red/green stateは許可ステータスです。
低レベルのテストが緑色の場合、新しい例を作成したり、既存の実装をリファクタリングしたりする権限があります。リファクタリングのコンテキストでは、新しい機能/柔軟性を追加してはなりません。
低レベルのテストが赤の場合、既存のテストを緑にするためだけに実装コードを記述または変更する権限があります。存在しない次のテストに合格するためのコードを記述したいという衝動に抵抗するか、優れていると思われる機能を実装する必要があります（顧客は尋ねなかったでしょう）。