BDDの2番目のステップ-「失敗したシナリオのステップ」と書いてください、それはそれに対するテストを意味しますか？
BDDは「テスト」という用語の使用を何らかの形で回避していることを知っているので、「エンタープライズアジリティへの旅：システムの思考と組織の遺産」と呼ばれる本で説明されているプロセスを理解しようとしています。
彼らはそのようなBDDプロセスを説明しています：
- 機能からシナリオを選択
- 失敗したシナリオのステップを書く
- 失敗したステップで詳述されている動作をサポートするために失敗したテストを作成します
- ユニットテストに合格するためのコードを書く
- リファクタリング
- ステップがパスした場合は、次のステップに進みます。そうでない場合は、ステップがパスするまで詳細な動作をサポートするオブジェクトをさらに検出します。
「与えられた」、「いつ」、「その後」はステップと見なされます。
サンプルシナリオは、「製品の詳細ページにいるとします。」でした。
図の下で、彼らは説明します：...
次のアクションは、失敗したシナリオのステップを作成することです。この場合、製品ページを表示できることを確認するコードを作成します。
理解できません。テストでない場合、失敗したシナリオのステップは何ですか（ステップ4で言及されているように、テストではないようです）。それがテストではない場合（ただし、他のコード）、TDDルールに違反していませんか（最初にテスト）。
シナリオは、人間が読めるテキストの一部です。ここで失敗するシナリオのステップを記述するとは、シナリオの一部を実行可能なテストコードに変換することを意味します。これにより、シナリオが実装されているかどうかを自動的に確認できます。
Cucumberを使用してシナリオを記述している場合、これは特に明らかです。 Cucumberテストランナーはシナリオを解析しますが、各ステップを未実装としてマークします。したがって、まず必要なコードを記述して、そのステップを解析および実行する必要があります。つまり、シナリオをテストに変換します。これらの手順の一部またはすべてが最初に失敗する場合があります。与えられた/いつ/その後のスタイルのシナリオでは、少なくとも「その後」のステップは失敗するはずです。ステップを作成するときに、シナリオを言い換えて解析を明確かつ簡単にすることもできます。
これで、失敗したステップを含む自動的にテスト可能なシナリオができました。次に、1つのステップを選択し、TDDループに移動します。TDDループでは、ユニットテストを記述し、そのステップが通過し始めるまでコードを記述します。それが完了したら、BDDループに戻り、次の失敗または実装されていない手順、または次のシナリオを続行します。
はい、シナリオをこのように扱うと、確かに一種のテストになります。ただし、自動的にテスト可能であることは二次的な問題にすぎず、シナリオは主に顧客またはドメインの専門家と開発者の間の明確なコミュニケーションに関するものです。 BDDスタイルのテスト/シナリオは、通常、高レベルのユーザー指向のエンドツーエンドであり、ビジネスルールに焦点を当てています。対照的に、単体テストは含まれています。 TDDスタイルのテストはより詳細であり、より小さなコンポーネントをカバーし、テスト中のコードのインターフェースにより関心があります。