TDD と BDD の主な違いは何ですか?

https://stackoverflow.com/questions/2509

08-06-2019
|

質問

テスト駆動開発は、ここ数年 .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 の比較については、こちらをご覧ください。ビデオ. 。また、BDD について「TDD は正しく行われている」という意見もあります。ジェレミー D.ミラー

2013 年 3 月 25 日更新

上の動画はしばらくの間公開されていませんでした。これはルウェリン・ファルコによる最近のものです。 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 は、プログラマーが機能するクリーンなコードを作成するために使用する低レベルの技術的方法論です。

行動主導型開発 は TDD に基づいて作成された方法論ですが、プログラマーとテスターだけに関係するのではなく、チーム全体と、技術的および非技術的な関係者すべてに関係するプロセスに進化しました。BDD は、TDD ではうまく答えられないいくつかの単純な質問から始まりました。どのくらいのテストを書けばいいですか?実際に何をテストすべきで、何をテストすべきでしょうか?私が作成するテストのうち、実際にビジネスや製品全体の品質にとって重要なものはどれですか?また、単なるオーバーエンジニアリングにすぎないものはどれですか?

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

一言で言えば、私が持っている BDD の最も優れた定義の 1 つです。見つかったこれまでのところ、BDDは「ドメインの専門家と会話し、例を使用して、望ましい行動を共有し、未知のものを発見することについてです。発見の部分は非常に重要です。配信チームがより多くの例を収集するにつれて、ビジネスドメインをますます理解し始め、対応しなければならない製品のいくつかの側面についての不確実性が軽減されます。不確実性が減少するにつれて、配信チームの創造性と自主性が高まります。たとえば、ビジネスユーザーがテクノロジーの専門知識がないために不可能だと考えていた独自の例を提案できるようになります。

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

もっと詳しく知る

BDD についてさらに詳しく知りたい場合は、このテーマに関する本を書きました。 「優れた仕様書を書く」 要件を分析する技術を探求し、優れた BDD プロセスを構築し、そのプロセスの中核部分として例を使用する方法を学ぶのに役立ちます。この本では、ユビキタス言語について説明し、サンプルを収集し、そのサンプルからいわゆる実行可能な仕様 (自動テスト) を作成します。これは、BDD チームが優れたソフトウェアを時間と予算内で提供するのに役立つテクニックです。

「優れた仕様書を書く」の購入に興味がある場合は、 39％節約できます プロモーションコード付き 39ニシエヤ2 :)

私は BDD アプローチを少し実験してみましたが、BDD はユースケースの実装には適しているものの、基礎となる詳細には適していないという時期尚早の結論に至りました。TDD は依然としてそのレベルで揺るぎません。

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

BDD の方が範囲が広いように思えます。これは、TDD が使用されていること、とりわけ、迅速なフィードバックを確保するために TDD 実践を使用するための情報と要件を収集する包括的な方法論が BDD であることを暗示しています。

BDD に関する私の最新の知識を TDD と比較した場合、BDD は次に何が起こるかを指定することに重点を置いているのに対し、TDD は一連の条件を設定して出力を確認することに重点を置いています。

動作駆動開発は、開発者間、さらには開発者とテスターの間の対話とコミュニケーションに重点を置いているようです。

ウィキペディアの記事には次のような説明があります。

行動主導型開発

私自身はBDDを実践していませんが。

TDD の主な利点は設計であると考えてください。それはテスト駆動設計と呼ばれるべきです。BDD は TDD のサブセットであり、動作駆動設計と呼ばれます。

次に、TDD (単体テスト) の一般的な実装について考えてみましょう。単体テストのユニットは通常、作成できる作業の最小単位である 1 ビットのロジックです。

これらのユニットを機能的な方法で組み合わせてマシンに望ましい動作を記述する場合、マシンに記述している動作を理解する必要があります。動作駆動設計は、ユースケース/要件/その他に関する実装者の理解を検証することに重点を置き、各機能の実装を検証します。BDD と TDD は一般に、設計に情報を提供するという重要な目的と、特に実装が変更された場合に実装の正しさを検証するという 2 番目の目的を果たします。BDD が正しく行われるには、ビジネスと開発 (および QA) が関係しますが、単体テスト (TDD の 1 つのタイプではなく TDD として誤ってみなされる可能性があります) は通常、開発サイロで行われます。

BDD テストは現実的な要件として機能することを付け加えておきます。

BDD は大部分が正しく行われた TDD です。ただし、BDD が提供する追加の価値もあります。それに関するリンクは次のとおりです。

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

簡単なスナップショットは次のとおりです。

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

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

BDD は、DDD のいくつかの側面を取り入れた TDD の実装です。

お役に立てば幸いです!

テスト駆動開発 (TDD) と動作駆動開発 (BDD) の違い

BDD は、システムの動作面ではなく、システムの動作面に焦点を当てます。
TDD が焦点を当てているシステムの実装面。
BDD により、システムが何をすべきかがより明確に理解できるようになります。
開発者と顧客の視点から。TDDのみ
開発者はシステムが何をすべきかを理解できます。
BDDにより、開発者と顧客の両方が、システムのソースコードに含まれる要件分析に協力することができます。

TDD と BDD の間に違いはありません。ただし、テストをよりよく読み取ることができ、要件として使用できます。BDD テストを作成するのと同じ単語で要件を作成すると、コードを作成できるように定義されたテストの一部をクライアントから受け取ることができます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow