ここ数年、.NET コミュニティではテスト駆動開発が大流行しています。最近、ALT.NET コミュニティで BDD に関する不満を耳にしました。それは何ですか?TDDとの違いは何ですか?
12 に答える
私は、BDDがテストよりも仕様に関するものであることを理解しています。ドメイン駆動設計にリンクされています(これらの* DDの頭字語は好きではありませんか?)。
これは、高レベルのテストを含む、ユーザーストーリーを書くための特定の方法とリンクしています。Tom ten Thijによる例:
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 グループもあります。
私はBDDアプローチを少し実験しましたが、私の時期尚早な結論は、BDDはユースケースの実装に適していますが、根本的な詳細には適していないということです。TDDはまだそのレベルで揺れ動いています。
BDDはコミュニケーションツールとしても使用されます。目標は、ドメインの専門家が理解できる実行可能仕様を作成することです。
BDD に関する私の最新の知識を TDD と比較すると、BDD は次に何が起こるかを指定することに重点を置いていますが、TDD は一連の条件を設定してから出力を確認することに重点を置いています。
TDD の主な利点は設計であると考えてください。それはテスト駆動設計と呼ばれるべきです。BDD は TDD のサブセットであり、ビヘイビア ドリブン デザインと呼ばれます。
ここで、TDD の一般的な実装である単体テストについて考えてみましょう。ユニット テストのユニットは通常、作成できる作業の最小単位である 1 ビットのロジックです。
これらのユニットを機能的な方法で組み合わせて、マシンに望ましい動作を記述する場合、マシンに記述している動作を理解する必要があります。動作駆動設計は、実装者がユースケース/要件/何でも理解していることを確認することに焦点を当て、各機能の実装を確認します。一般に、BDD と TDD は、設計を通知するという重要な目的と、特に変更時に実装の正確性を検証するという 2 番目の目的に役立ちます。適切に行われた BDD には biz と dev (および qa) が関与しますが、単体テスト (TDD の 1 つのタイプではなく、TDD と誤って見なされる可能性があります) は通常、開発サイロで行われます。
BDD テストは生活要件として機能することを付け加えておきます。
ビヘイビア駆動開発は、開発者間、および開発者とテスター間の相互作用とコミュニケーションに重点を置いているようです。
ウィキペディアの記事には説明があります:
ただし、自分で BDD を実践しているわけではありません。
BDD はより広い範囲のように思えます。これは、TDD が使用されていることをほぼ暗示しています。つまり、BDD は、TDD プラクティスを使用するための情報と要件を収集する包括的な方法論であり、とりわけ、迅速なフィードバックを確実にするためのものです。
簡単なスナップショットは次のとおりです。
TDD は、コードを記述する前にコードをテストするプロセスです。
DDD は、コードに触れる各サイクルの前にドメインについて通知されるプロセスです!
BDD は、DDD のいくつかの側面を取り入れた TDD の実装です。
TDD と BDD に違いはありません。ただし、テストをよりよく読むことができ、それらを要件として使用できます。BDD テストを記述するのと同じ言葉で要件を記述すれば、コードを記述できるように定義されたテストの一部をクライアントから受け取ることができます。