TDDとBDDの主な違いは何ですか？[閉まっている]

ここ数年、.NETコミュニティではテスト駆動開発が大流行しています。最近、ALT.NETコミュニティでBDDについて不平を言っています。それは何ですか？TDDと何が違うのですか？

BDDの詳細について理解している がテストよりも仕様ます。それはドメイン駆動設計にリンクされています（これらの* DD頭字語は好きではありませんか？）。

これは、高レベルのテストを含む、ユーザーストーリーを書くための特定の方法にリンクされています。トム・テン・ティジによる例：

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

（彼の記事では、トムはこのテスト仕様をRubyで直接実行します。）

BDDの法王であるダン・ノース。あなたは彼の素晴らしい紹介を見つけるでしょう紹介するBDDの記事。

このビデオでは、BDDとTDDの比較をご覧いただけます。ジェレミー・D・ミラーによる「TDDは正しく行われた」としてのBDDに関する意見も

2013年3月25日更新

上のビデオはしばらくの間行方不明になっています。Llewellyn Falcoによる最近の記事、BDDとTDDについて説明します。私は彼の説明が明確で要領を得ていると思います。

私にとってBDDとTDDの主な違いは、焦点と表現です。そして言葉はあなたの意図を伝えるために重要です。

TDDはテストに焦点を合わせます。そして、「古い滝の世界」ではテストは実装後に行われるため、この考え方は誤った理解と行動につながります。

BDDは動作と仕様に焦点を当てているため、滝のマインドは混乱しています。したがって、BDDは、テストの実践ではなく、設計の実践としてより簡単に理解できます。

BDDには2つのタイプがあるようです。

1つ目は、Dan Northが話し合ってxBehaveスタイルフレームワークを作成した元のスタイルです。私にとって、このスタイルは、主にドメインオブジェクトに対する受け入れテストまたは仕様に適用できます。

2番目のスタイルは、Dave Astelsが普及したものであり、私にとっては、いくつかの重大な利点を持つTDDの新しい形式です。これは、テストではなく動作と小さなテストクラスに焦点を当てており、基本的に、仕様（テスト）メソッドごとに1行あるようにしています。このスタイルはすべてのレベルのテストに適しており、既存の単体テストフレームワークを使用して実行できますが、新しいフレームワーク（xSpecスタイル）は、テストではなく動作に焦点を当てるのに役立ちます。

役立つBDDグループもあります。

http://groups.google.com/group/behaviordrivendevelopment/

テスト駆動開発はテストファーストのソフトウェア開発方法論です。つまり、テストされる実際のコードを書く前にテストコードを書く必要があります。ケントベックの言葉で：

ここでのスタイルは、数行のコードを記述してから、実行する必要があるテストを記述し、実行しないテストを記述して、それを実行させるコードを記述します。

小さなコードを1つ書く方法を理解したら、今度はコーディングするのではなく、すぐにフィードバックを得て、「少しコーディングして、少しテストして、少しテストして、少しテストする」練習をしたいと思います。そのため、すぐにテストを作成します。

したがって、TDDは、プログラマが機能するクリーンなコードを生成するために使用する低レベルの技術的手法です。

Behavior-Driven Developmentは、TDDに基づいて作成された方法論ですが、プログラマーやテスターだけに関係するのではなく、チーム全体と、技術的および非技術的なすべての重要な利害関係者を扱うプロセスに進化しました。BDDは、TDDがうまく答えられないいくつかの簡単な質問から始まりました。実際に何をテストすべきか、そして何をテストすべきでないか？私が書いたテストのうち、実際にビジネスまたは製品の全体的な品質にとって重要なものはどれですか。また、どれが私の過大なエンジニアリングですか。

ご覧のとおり、このような質問にはテクノロジーとビジネスのコラボレーションが必要です。多くの場合、ビジネスの利害関係者やドメインの専門家は、どのようなテストが役立つと思われるかをエンジニアに伝えることができます。ただし、テストが重要なビジネスの側面を扱う高レベルのテストである場合に限ります。BDDは、「この機能が正しく動作する方法の例を教えて」のように、ビジネスに似たテストを「例」と呼び、データ検証やAPI統合のテストなどの低レベルの技術チェックのために「テスト」という語を予約しています。重要な部分は、テストはプログラマーとテスターだけが作成できる一方で、デザイナーやアナリストなど、デリバリーチーム全体がサンプルを収集して分析できることです。

これまでに見つけた BDDの最も優れた定義の1つは、BDDが「ドメインの専門家と会話し、例を使用して目的の動作について共通の理解を得て、未知のものを発見する」ことです。発見の部分は非常に重要です。デリバリーチームがより多くの例を収集するにつれて、彼らはビジネスドメインをますます理解するようになり、したがって、対処する必要がある製品のいくつかの側面についての不確実性を減らします。不確実性が減少すると、デリバリーチームの創造性と自律性が高まります。たとえば、技術的な専門知識がないためにビジネスユーザーが不可能だとは考えていなかった独自の例を提案できるようになりました。

現在、ビジネスやドメインの専門家との会話は素晴らしいように聞こえますが、実際にそれがどのように終わるかはよくわかります。プログラマーとしてのテクノロジーから旅を始めました。プログラマーとして、アルゴリズム、設計パターン、抽象化などのコードを書くことを教えられています。または、あなたがデザイナーなら、デザインすることを教えられます-情報を整理し、美しいインターフェイスを作成します。しかし、私たちがエントリーレベルの仕事を得るとき、雇用主は私たちが「クライアントに価値を提供する」ことを期待しています。そして、それらのクライアントの中には、例えば...銀行があります。しかし、銀行口座については、口座残高を効率的に減らす方法を除いて、ほとんど何も知りませんでした。だから私はどういうわけか私に期待されていることをコードに変換する必要があります...何か価値を提供したいのであれば、銀行と私の技術的専門知識との間に架け橋を築かなければなりません。BDDは、デリバリーチームとドメインエキスパートの間の流動的なコミュニケーションの安定した基盤の上に、そのようなブリッジを構築するのに役立ちます。

もっと詳しく知る

BDDの詳細を読みたい場合は、この件について本を書きました。「Writing Great Specifications」は、要件を分析する技術を探求し、優れたBDDプロセスを構築し、そのプロセスのコア部分として例を使用する方法を学ぶのに役立ちます。この本は、ユビキタス言語、例の収集、および例からいわゆる実行可能な仕様（自動テスト）の作成について述べています。BDDチームが優れたソフトウェアを時間通りに予算内で提供するのに役立つ技術です。

あなたが購入に興味を持っている場合は、「ライティンググレート仕様、」あなたは39％を保存することができプロモーションコードを39nicieja2 :)

私はBDDアプローチを少し試してみましたが、私の早期の結論は、BDDはユースケースの実装に適しているが、根本的な詳細には適していないということです。TDDはまだそのレベルで揺れ動いています。

BDDは、コミュニケーションツールとしても使用されます。目標は、ドメインの専門家が理解できる実行可能な仕様を作成することです。

BDDはより広い範囲であるように私には思えます。これは、TDDが使用されていることをほとんど意味します。BDDは、特に迅速なフィードバックを確実にするためにTDDプラクティスを使用するための情報と要件を収集する包括的な方法です。

TDDと比較したときのBDDの最新の知識により、BDDは次に何が起こるかを指定することに焦点を当てますが、TDDは一連の条件を設定して出力を確認することに焦点を合わせます。

振る舞い駆動型開発は、開発者間および開発者とテスター間の相互作用とコミュニケーションにより重点を置いているようです。

ウィキペディアの記事には説明があります：

行動主導の開発

自分でBDDを練習していない。

TDDの主な利点を設計であると考えます。それはテスト駆動設計と呼ばれるべきです。BDDはTDDのサブセットで、ビヘイビア駆動設計と呼ばれます。

次に、TDD-ユニットテストの一般的な実装を検討します。ユニットテストのユニットは、通常、実行できる作業の最小単位である1ビットのロジックです。

これらのユニットを機能的な方法でまとめて、マシンに望ましい動作を説明する場合、マシンに説明する動作を理解する必要があります。Behavior Driven Designは、ユースケース/要件/何でも実装者の理解を検証することに焦点を当て、各機能の実装を検証します。BDDとTDDは一般に、設計に通知するという重要な目的と、特に変更があった場合に実装の正確さを検証するという2番目の目的に役立ちます。正しく行われるBDDにはbizとdev（およびqa）が含まれますが、ユニットテスト（1つのタイプのTDDではなくTDDとして誤って表示される可能性があります）は通常、開発サイロで行われます。

BDDテストは実際の要件として機能することを付け加えます。

BDDは、主にTDDが正しく行われています。ただし、BDDが提供する付加価値があります。これに関するリンクは次のとおりです。

BDDは「TDDが正しく行われる」以上のものです

TDDとBDDの間に違いはありません。ただし、テストを読みやすく、要件として使用できます。BDDテストを作成するのと同じ言葉で要件を作成する場合、コードを作成する準備ができているテストのいくつかをクライアントから取得できます。

テスト駆動開発（TDD）と動作駆動開発（BDD）の違い

• BDDは
  、TDDが重点を置くシステムの実装の側面ではなく、システムの動作の側面に重点を置いています。

• BDDは
  、開発者と顧客の観点からシステムが何をすべきかについてより明確な理解を提供します。TDD
  は、開発者にシステムが何をすべきかを理解させるだけです。

• BDDを使用すると、開発者と顧客の両方が、システムのソースコードに含まれている要件分析に取り組むことができます。

つまり、TDDとBDDの間には大きな違いがあります。TDDでは主にテストデータに焦点を当てています。BDDでは主にプロジェクトの動作に焦点を当てているため、非プログラミング担当者は、その方法

これが簡単なスナップショットです。

• TDDは、コードを記述する前にコードをテストするプロセスにすぎません。

• DDDは、コードに触れる各サイクルの前にドメインについて通知を受けるプロセスです。

• BDDは、DDDのいくつかの側面をもたらすTDDの実装です！