1. 序章

ビヘイビア駆動開発（ BDD ）は、ビジネス要件を満たすことを目的としたソフトウェア開発プロセスです。

このチュートリアルでは、BDDを詳細に分析します。 さらに、その祖先であるテスト駆動開発（ TDD ）を紹介します。 最後に、両方を比較します。

2. TDD

BDDとTDDのアプローチは、共通の要素を共有しています。 したがって、BDDを完全に理解するには、TDDを簡単に定義する必要があります。 テスト駆動開発は、テストの作成を目的としたソフトウェア開発手法です。 TDDを使用して、機能を実装する前にテストを作成することから始めます。

2.1. 赤/緑/リファクタリング

TDD開発サイクルはしばしば赤/緑/リファクタリングと呼ばれます。これらはTDDワークフローの3つの重要なフェーズです。

最初のフェーズは赤いフェーズです。 その間、必要な機能の一部のテストを作成することから始めます。 機能がまだ実装されていないため、テストは失敗する必要があります。 どういうわけかテストに合格した場合、それはそれがひどく書かれていることを意味し、修正する必要があります。 ほとんどのIDEは、テストの失敗を赤い色のメッセージで通知します。 そのため、このフェーズは赤と呼ばれます。

グリーンフェーズでは、テストに合格するための最小限のコードを記述します。 そのフェーズでは、コードの品質は重要ではありません。 テストをカバーするためだけに、実装は迅速かつ最小限である必要があります。

最後のリファクタリングフェーズでは、機能を変更せずにコード品質を向上させます。 したがって、クリーンアップ後もテストは合格するはずです。 コードをリファクタリングしている間、テストを実行する必要があります。 したがって、潜在的なエラーは簡単に見つけて修正できます。

 

3. BDD

BDDの主な目的は、技術者と非技術者（ビジネス関連）の人々が効果的に協力できるようにするツールを提供することです。 したがって、ソフトウェアはビジネス要件、特にユーザーシナリオに基づいて実装されます。 その後、 BDDは、すべてのチームが簡単に作業できる自然なドメイン固有言語を推奨します。 技術的に言えば、BDDはTDDとドメイン駆動設計の組み合わせです。

BDDのコアコンセプトを定義しましょう。

3.1. 基礎

BDDアプローチには3つの主要なルールがあります。

  1. いい加減にしろ
  2. ステークホルダーに価値を提供する
  3. それはすべて行動です

ルールは簡単です。 「十分」とは、本当に必要なものだけを分析、計画、設計する必要があることを意味します。 さらに、要件は通常時間の経過とともに変化するため、プロジェクトの全範囲を一度に指定する時間を無駄にしないでください。 言い換えれば、プロジェクトの開始に必要なタスクのみを実行する必要があります。他のすべての作業は無駄です。

利害関係者とは、成果プロジェクトに関心を持つ個人またはグループです。 プロジェクトに関連するすべての活動は、ビジネス価値を提供する必要があります。 したがって、2番目のルールでは、ビジネス価値をもたらさない努力を避ける必要があります。 その後、プロジェクトに含まれる機能はすべて価値があると見なされます。

最後に、プロジェクトのすべての参加者は、ユビキタス言語を使用して、プロジェクトの任意のレベル（コード、アプリケーション、ビジネス）での動作を説明できる必要があります。 重要なのは、技術者と非技術者のギャップを縮めることです。 したがって、要件は、ユーザーストーリーとシナリオを使用して定義されます。 Gherkin のように、その目的のために特化された、ビジネスで読み取り可能な言語が存在します。

3.2. ワークフロー

BDDは、次のステップのサイクルで構成されます。

  1. ビジネス機能を特定する
  2. 機能のシナリオと受け入れ基準を定義する
  3. シナリオごとのステップを決定する
  4. 実装されていない機能の失敗したテスト手順を記述します
  5. テストステップに合格するコードを記述し、
  6. コードをリファクタリングする
  7. レポートを作成する

まず、利害関係者とビジネスアナリストがビジネスニーズについて話し合い、特定します。 次に、テスターと一緒にストーリーを作成します。 ストーリーは文書化されたビジネス要件です。

各ストーリーには、タイトル、ナレーション、および受け入れ基準が必要です。 ナレーションは、機能の説明、その利点、および有益性を定義します。 すでに述べたように、ストーリーとその手順は、ビジネスで読み取り可能な言語で作成する必要があります。 物語の一般的な形を見てみましょう：

Feature: [title]
    As a [role/beneficent]
    I want [feature]
    So that [benefit]

オンラインショップアプリケーションのストーリーの実際の例を見てみましょう。

Feature: Account registration
    As a client
    I want to register an account
    So that I don't need to enter my data with every purchase

受け入れ基準は、ストーリーがいつ完了するかを指定します。 それらは通常次の形式をとるシナリオの形式で書かれています：

Scenario: title
    Given context
    When event
    Then result

以前のアカウント登録機能の簡単なシナリオを見てみましょう。

Scenario: Email address validation
    Given I'm an unregistered user
    When I enter the email address on the registration form page
    Then the email address must be correct and not taken

ストーリーとシナリオの準備ができたら、赤/緑/リファクタリングの開発サイクルを開始できます。

機能が実装された後、最終的にテストレポートを生成できます。 Cucumber 、 Serenity 、 Concordion 、 Mocha など、BDDテストの目的で使用されるさまざまなテクノロジーに特化したフレームワークがあります。

結局のところ、計画されている次の機能に対してBDDサイクルを繰り返します。

4. TDDとBDD

まず第一に、BDDは、プロジェクトの機能をユビキタス言語を使用した動作として記述することを目的としています。 したがって、技術的および非技術的の両方のすべての参加者に貢献します。 一方、TDDは実装プロセスに厳密に焦点を当てています。 したがって、ソフトウェア開発者がその主な貢献者です。

次に、 BDDプロセスは、ビジネスニーズを特定し、ストーリーとシナリオを作成することから始まります。 したがって、ドキュメントはすべてのプロジェクト参加者が簡単に理解できます。 それに比べて、TDDサイクルはテストの実装から始まります。 さらに、重要なドキュメントはテスト自体です。 その後、特定のプログラミング言語で書かれたテストは、技術者だけが読むことができます。

以下では、BDDシナリオはエンドユーザーの動作に依存しています。 したがって、機能の変更による大きな影響はありません。 一方、TDDでは、機能の変更が多くのテストケースに影響を与える可能性があります。

最後に、 BDDの展開は、より困難で時間がかかる可能性があります。 これには、開発者、テスター、QA、ビジネス分析、および利害関係者のコラボレーションが必要です。 TDDは主に開発者間のコラボレーションを要求しますが。 それでも、BDDサイクルにはTDDの赤/緑/リファクタリングプロセスが含まれています。 したがって、BDDプロセスは著しく広い概念です。

5. 結論

要約すると、BDDとTDDは異なるアプローチです。 BDDは、 eコマースなどのエンドユーザーの動作や、銀行のソフトウェア、インターネットブラウザ、ゲームなどのアプリケーションシステムに大きく依存するプロジェクトに適しています。 対照的に、TDDは、APIやサードパーティのフレームワークなど、BDDが圧倒的であるか、適用が難しいプロジェクトでうまく機能します。