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

このギブアンドアンドホエンアンドザアンドアンド構文は、行動駆動型開発では一般的です。それの利点の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のスーパーセットと見なすことができます。それは時間の経過とともに成長し、より多くの要件抽出側を含むようになりましたが、それでも開発プロセス側はその中核部分です。

そのため、BDDの適切な部分であるTDDに対処します。BDDは、プロセスの意図を明確にするためのTDDの言語の変更として始まりました。 Dan Northの BDDに関する入門記事では、テストではなく動作という言葉に焦点を当てるのがなぜ役に立つのかを説明しています。これは、ソフトウェアを正しく構築しているだけでなく、適切なソフトウェアを構築していることを確認するのに役立ちます。これは常に優れたTDDアプローチの一部でしたが、ダンはそれをBDDに成文化しました。

私が思うに、BDDはTDDよりも少し明確にしたり、少なくとも公式化してツールサポートを提供したりするのは、この2サイクル/ダブルループ/ズームインズームアウト/アウトサイドインアプローチです。まず、機能の予想される動作（外側のループ）を説明し、次に内側のループにズームインして、低レベルの仕様に対処します。

http://www.metesreau.com/ncraft-workshop/ から

GherkinはCucumberやSpecFlowなどのツールと組み合わせて、これらの高レベルの機能仕様を記述し、アプリケーションコードを実行するコードにリンクする方法を提供します。私は、これがBDDがTDDとは異なると感じるかもしれないと主張しますが、実際には同じことを行っており、ツールサポートとDSLが追加されています。「従来の」TDDに少し近いのは、rspec、nspec、spockなどのツールを使用することです。これらは、「従来の」TDDで行うのと同じプロセスに少し似ていますが、より行動に焦点を当てた言語を使用します。

で活動するBDD（強く推奨）ジョン・ファーガソンスマートによって、彼はその後、低レベルの仕様については、スポックのようなツールに落下、外側のレベルの実行可能な仕様でjBehaveのようなものから始めて、ダブルループアプローチを提唱しています。

BDDは、テスト駆動の概念をビジネスの利害関係者により近づけます。Gherkinはビジネスで読めるように設計されており、「リビングドキュメント」、つまり実行可能な仕様から自動的に生成される進捗レポートのアイデアは、利害関係者にフィードバックを与えることです。

現在のBDDのもう1つの部分は、それが本当に大規模なプロセスの一部としてTDDを組み込むものになる場所であり、要件の引き出しの要素です。機能インジェクション、インパクトマッピング、リアルオプションなどのアイデアは、この側面の一部です。

これに関する標準的な回答については、ダンノースに再度行くのが最善かもしれません。チームがすべて開発者である場合、BDD = TDDです。チームにさまざまな利害関係者が関与している場合、BDDはXPに近く、TDDはその一部です。

BDDとTDDの関係は何ですか？

それらは同じものです。

私が理解したことから、BDDはTDDを超える2つの主なものを追加します：テストの命名（保証/すべき）

それは実際にはBDDが「追加」するものではありません。これは、TDDの教育と理解を容易にするための別の規則です。

BDDを作成した人たちはすべてTDDを教えていましたが、理解するのが最も難しいのは、TDDがテストとはまったく関係がないということです。学生がそのハードルを乗り越えると、彼らにとってははるかに簡単になりました。しかし、「テスト」という言葉（または「アサート」などの関連用語）が実際にどこにでも現れる場合、テストについて考えることから離れることは非常に困難です。そこで、彼らはいくつかの言葉を入れ替えました。

しかし、それは言葉だけです！TDDとBDDの間に実際の違いはありません。

および受け入れテスト。

受け入れテストは、BDDと同様にTDDの重要な部分です。繰り返しますが、TDDとBDDの間に違いはありません。TDD が正しく行われているのは BDD、BDD は TDDが正しく行われています。