BDDとTDDの関係
BDDとTDDの関係は何ですか？
私が理解したことから、BDDはTDDに2つの主要なものを追加します。テストの命名（保証/推奨）と受け入れテストです。 BDDによる開発中はTDDに従う必要がありますか？はいの場合、TDD単体テストは同じ確認/スタイルで名前を付ける必要がありますか？
BDDはTDDサイクルの周りにサイクルを追加します。
ですから、あなたは振る舞いから始めて、それがあなたのテストを動かし、それからそのテストが開発を動かします。理想的には、BDDはある種の受け入れテストによって駆動されますが、100％である必要はありません。期待される動作が定義されている限り、問題はありません。
それで、あなたがログインページを書いているとしましょう。
ハッピーパスから始めましょう：
Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page
この「Given-And-When-And-Then-And」構文は、行動主導型の開発では一般的です。これの利点の1つは、開発者以外のユーザーが（およびトレーニングを使用して）読み取ることができることです。つまり、利害関係者は、タスクを正常に完了するために定義した動作のリストを表示して、それが完了しているかどうかを確認できます。あなたが不完全な製品をリリースするずっと前に彼らの期待に一致します。
上記によく似たGherkinと呼ばれるスクリプト言語があり、これらの動作の句の背後にテストコードを記述できます。通常の開発フレームワークには、Gherkinベースのトランスレータを探す必要があります。それはこの回答の範囲外です。
とにかく、行動に戻ります。現在のアプリケーションはまだこれを行っていません（その場合、なぜ誰かが変更を要求しているのですか？）。したがって、テストランナーを使用している場合でも、手動でテストしている場合でも、このテストは失敗します。
それでは、TDDサイクルに切り替えて、その機能を提供する時が来ました。
BDDを作成するかどうかに関係なく、テストには一般的な構文の名前を付ける必要があります。最も一般的なものの1つは、説明した「should」構文です。
テストを記述します：ShouldAcceptValidDetails。満足するまでRed-Green-Refactorサイクルを繰り返します。行動テストに合格しましたか？そうでない場合は、別のテストを作成してください：ShouldRedirectToUserDefaultPage。あなたが幸せになるまで赤緑リファクタリング。行動に定められた基準を満たすまで、洗い、すすぎ、繰り返します。
次に、次の動作に移ります。
Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"
これで、以前の動作をパスするためにこれを横取りしてはなりません。この時点でこのテストに失敗するはずです。 TDDサイクルに戻ってください。
そして、あなたがあなたのページを持っているまで続きます。
Ruby開発者でない場合でも、BDDとTDDの詳細については The Rspec Book を強くお勧めします。
それについての私の理解：
- BDDは、行動への焦点を明確にするためのTDDのブランド変更から始まりました。
- これは、動作と実行可能仕様に焦点を合わせるためのより正式なサポート（DSLおよびツール）を提供します。
- BDDはTDDのスーパーセットと見なすことができます。それは時間の経過とともに成長し、要件の導出側の多くを包含するようになりましたが、それでも開発プロセス側はその中核部分です。
TDDに対処するには、BDDの正しい部分を実行します。 BDDは、プロセスの意図を明確にするためにTDDの言語の変更として始まりました。 Dan Northの紹介記事 BDDは、テストではなくWordの動作に注目することが役立つ理由を説明しています。これは、ソフトウェアを正しく構築しているだけでなく、適切なソフトウェアも構築していることを確認するのに役立ちます。これは常に良いTDDアプローチの一部でしたが、Danはそれを少しBDDに体系化しました。
BDDがTDDよりも少し明示的である、または少なくとも形式化してツールサポートを提供していると私が思うのは、この2サイクル/ダブルループ/ズームインズームアウト/アウトサイドインアプローチです。まず、機能の予想される動作（外側のループ）について説明し、次に内側のループにズームインして、低レベルの仕様に対処します。
から http://www.metesreau.com/ncraft-workshop/ から
Gherkinは、CucumberやSpecFlowなどのツールと組み合わせて、これらの高レベルの機能仕様を記述し、アプリケーションコードを実行するコードにリンクする方法を提供します。これはBDDがTDDと「感じる」可能性がある場所であると私は主張しますが、ツールサポートとDSLを追加しただけで、実際には同じことを実行しています。 「従来の」TDDに少し近いのは、rspec、nspec、spockなどのツールを使用することです。これらは、「従来の」TDDで行うのと同じプロセスに少し似ていますが、より行動重視の言語を使用しています。
BDD in Action によってJohn Ferguson Smart（強く推奨）は、ダブルループアプローチを提唱し、外部レベルの実行可能仕様でjBehaveのようなものから始めて、低レベルのSpockのようなツールにドロップしますレベルの仕様。
BDDは、テスト主導の概念をビジネスの利害関係者により近づけます。ガーキンはビジネスが読みやすいように設計されており、「生きたドキュメンテーション」、つまり実行可能な仕様から自動的に作成される進捗レポートのアイデアは、利害関係者にフィードバックを提供することです。
現在、BDDのもう1つの部分は、より大きなプロセスの一部としてTDDを本当に組み込むものになっていますが、要件抽出のビットとピースです。機能注入、影響マッピング、リアルオプションなどのアイデアは、この側面の一部です。
これに関する標準的な回答については、 もう一度Dan Northに移動する が最適です。チームがすべての開発者の場合、BDD = TDDです。チームにさまざまな関係者が関与している場合、BDDはXPに近く、TDDはその一部です。
BDDとTDDの関係は何ですか？
彼らは同じものです。
私が理解したことから、BDDはTDDに2つの主なものを追加します：テストの命名（保証/すべき）
これは実際にはBDDが「追加」するものではありません。これは、TDDをより簡単に教えて理解できるようにすることを意図した別の規則にすぎません。
BDDを作成した人々はすべてTDDを教えていて、理解するのが最も難しいのはTDDがテストとはまったく関係がないということでした。学生がそのハードルを乗り越えると、彼らにとってはるかに簡単になりました。しかし、テストについて考えることから自分自身を離婚することは非常に難しい、 「テスト」という言葉（または「アサート」などの関連用語）は、どこにでもどこにでも表示されます。それで、彼らはいくつかの言葉を入れ替えました。
しかし、それはのみの言葉です！ TDDとBDDの間には実際にはnoの違いがあります。
そして受け入れテスト。
受け入れテストはTDDの一部であり、BDDの場合と同じくらい重要です。繰り返しますが、TDDとBDDの間に違いはありません。TDDは正しく行われますisBDD、BDDisTDDは正しく行われました。