ビヘイビア駆動開発-クイックガイド

ビヘイビア駆動開発（BDD）は、もともとテスト駆動開発（TDD）から生まれたソフトウェア開発プロセスです。

BDDの進化を担当するDanNorth氏によると、「BDDは複数のレベルの例を使用して、重要なソフトウェアを提供するための共通の理解と表面的な不確実性を生み出しています。」

BDDは、例を使用して、開発に関与するすべての人が読みやすく理解できる言語で記述されたシステムの動作を説明します。これらの例には以下が含まれます-

• 実行可能な仕様に変換されます。

• 受け入れテストとして使用されます。

BDD –主な機能

ビヘイビア駆動開発は-に焦点を当てています

• ソフトウェア開発者、ビジネスアナリスト、および利害関係者とのコミュニケーションを促進する共有プロセスと共有ツールを提供して、ビジネス価値のある製品を提供することを目的として、ソフトウェア開発で協力します。

• システムがどのように実装されるべきかではなく、システムが何をすべきか。

• 読みやすさと視認性を向上させます。

• ソフトウェアの動作だけでなく、顧客の期待を満たしていることも確認します。

BDDの起源

欠陥が適切なタイミングで検出されず、検出された時点で修正されない場合、欠陥を修正するためのコストは何倍にも増加します。次の例を考えてみましょう。

これは、要件が正しく取得されない限り、後の段階で要件を誤解したことに起因する欠陥を修正するのに費用がかかることを示しています。さらに、最終製品は顧客の期待に応えられない可能性があります。

時間の必要性は、次のような開発アプローチです。

• 要件に基づいています。

• 開発全体の要件に焦点を当てています。

• 要件が満たされていることを確認します。

上記の要件に対応できる開発アプローチはBDDです。したがって、行動主導型開発-

• システムのさまざまな予想される動作の例を導き出します。

• ビジネスドメインの用語を使用した言語で例を記述できるため、顧客を含む開発に携わるすべての人が簡単に理解できます。

• 会話を介して、顧客と随時承認された例を取得します。

• 開発全体を通して、顧客の要件（例）に焦点を当てます。

• 受け入れテストとして例を使用します。

BDDプラクティス

BDDの2つの主な慣行は次のとおりです。

• 例による仕様（SbE）

• テスト駆動開発（TDD）

例による仕様

例による仕様（SbE）は、会話の例を使用して、ビジネスルールと構築するソフトウェアの動作を示します。

例による仕様により、製品の所有者、ビジネスアナリスト、テスター、および開発者は、ビジネス要件に関する一般的な誤解を排除できます。

テスト駆動開発

テスト駆動開発は、BDDのコンテキストで、例を人間が読める実行可能な仕様に変換します。

開発者は、これらの仕様をガイドとして使用して、新しい機能の増分を実装します。これにより、無駄のないコードベースと一連の自動回帰テストが実現し、ソフトウェアの存続期間を通じてメンテナンスコストを低く抑えることができます。

アジャイルBDD

アジャイルソフトウェア開発では、保留中の仕様について共通の理解を得るためにBDDメソッドが使用されます。

次の手順はアジャイルBDDで実行されます-

• 開発者と製品所有者は、プレーンテキストエディタで保留中の仕様を共同で作成します。

• 製品の所有者は、システムに期待する動作を指定します。

• 開発者

  • これらの動作の詳細を仕様に入力します。

  • システムの理解に基づいて質問します。

• 現在のシステムの動作は、新しい機能が既存の機能のいずれかを壊すかどうかを確認するために考慮されます。

アジャイルマニフェストとBDD

アジャイルマニフェストは次のように述べています-

私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることによって、ソフトウェアを開発するより良い方法を発見しています。この仕事を通して、私たちは価値に到達しました-

• Individuals and interactions −プロセスとツールについて

• Working software −包括的なドキュメント

• Customer collaboration −契約交渉について

• Responding to change −計画に従うこと

つまり、右側のアイテムには価値がありますが、左側のアイテムには価値があります。

BDDは、次のようにアジャイルマニフェストに合わせます。

アジャイルマニフェスト	BDDアライメント
プロセスとツールを介した個人と相互作用。	BDDは会話をすることです。
包括的なドキュメント上で動作するソフトウェア。	BDDは、ビジネス価値のあるソフトウェアを簡単に作成できるようにすることに重点を置いています。
契約交渉をめぐる顧客のコラボレーション。	BDDは、開発が進むにつれて顧客と継続的にコミュニケーションをとるアイデアに基づくシナリオに焦点を合わせています。それはいかなる約束にも基づいていません。
計画に従った切り替えへの対応。	BDDは、変化の吸収を促進する継続的なコミュニケーションとコラボレーションに重点を置いています。

ビヘイビア駆動開発に関する参考資料を見ると、「BDDはTDDから派生している」、「BDDとTDD」などのフレーズの使用法がわかります。BDDがどのように生まれたのか、なぜそれがTDDから派生したと言われるのか、そしてBDDとTDDとは何かを知るには、TDDを理解する必要があります。

なぜテストするのですか？

まず、テストの基本について説明します。テストの目的は、構築されたシステムが期待どおりに機能していることを確認することです。次の例を考えてみましょう。

したがって、経験から、欠陥が発生したときにそれを発見し、すぐに修正することが費用効果が高いことがわかりました。したがって、開発とテストのすべての段階でテストケースを作成する必要があります。これは、私たちの伝統的なテスト手法が私たちに教えてくれたことであり、しばしばテストアーリーと呼ばれます。

このテストアプローチは、ステージの完了後にテストが行​​われるため、テストラストアプローチと呼ばれます。

テストラストアプローチの課題

Test-Lastアプローチは、ソフトウェア開発プロジェクトでかなり長い間続いていました。ただし、実際には、このアプローチでは、テストは特定の段階が完了するまで待機する必要があるため、次の理由で見落とされることがよくあります。

• ステージの完了の遅れ。

• タイトなタイムスケジュール。

• テストをスキップして、時間通りに配達することに焦点を合わせます。

さらに、Test-Lastアプローチでは、開発者によって実行されるはずのユニットテストがスキップされることがよくあります。見つかったさまざまな理由は、開発者の考え方に基づいています-

• 彼らは開発者であり、テスターではありません。

• テストはテスターの責任です。

• それらはコーディングにおいて効率的であり、それらのコードには欠陥がありません。

これにより、-

• 提供される製品の品質を損なう。

• テスターのみの品質に対する説明責任を持つ。

• 欠陥の修正、納品後の高コスト。

• 顧客満足を得ることができないことは、リピートビジネスの喪失を意味し、したがって信頼性に影響を及ぼします。

これらの要因は、テストに焦点を合わせるために、パラダイムの転換を要求しました。その結果がテストファーストアプローチでした。

テストファーストアプローチ

Test-Firstアプローチは、インサイドアウト（コードを記述してからテスト）をアウトサイドイン（テストを記述してからコード）の開発方法に置き換えます。

このアプローチは、次のソフトウェア開発方法論（アジャイルでもあります）に組み込まれています-

• eXトレム Programming（XP）。

• TEST（東部基準時 Dリベン D開発（TDD）。

これらの方法論では、開発者は、コードモジュールの1行を記述する前に、コードモジュールの単体テストを設計および記述します。次に、開発者は単体テストに合格することを目的としてコードモジュールを作成します。したがって、これらの方法論では、単体テストを使用して開発を推進します。

目標はテストに基づく開発であることに注意する基本的なポイント。

赤-緑-リファクタリングサイクル

テスト駆動開発は、単体テストによって導かれるコードを開発するために使用されます。

Step 1 −作成するコードモジュールについて考えてみます。

Step 2 −テストを書く

Step 3 −テストを実行します。

コードがまだ書かれていないため、テストは失敗します。したがって、ステップ2は通常、失敗するテストの作成と呼ばれます。

Step 4 −テストに合格するために可能な最小限のコードを記述します。

Step 5−すべてのテストを実行して、すべてがまだ合格していることを確認します。ユニットテストは、このステップを容易にするために自動化されています。

Step 6 −リファクタリング。

Step 7 −次のコードモジュールについて、ステップ1からステップ6を繰り返します。

各サイクルは非常に短くする必要があり、通常の1時間には多くのサイクルが含まれている必要があります。

これは一般に Red-Green-Refactor サイクル、ここで-

• Red −失敗するテストを書く。

• Green −テストに合格するためのコードを書く。

• Refactor −重複を削除し、コードを許容可能な標準に改善します。

TDDプロセスステップ

TDDプロセスのステップを以下に示します。

TDDの利点

テスト駆動開発の利点または利点は次のとおりです。

• 開発者は、コードを作成する前に、最初に、望ましい結果がどうあるべきか、そしてそれをテストする方法を理解する必要があります。

• コンポーネントのコードは、テストに合格してコードがリファクタリングされたときにのみ終了します。これにより、開発者が次のテストに進む前に、テストとリファクタリングが保証されます。

• ユニットテストのスイートは各リファクタリングの後に実行されるため、各コンポーネントがまだ機能しているというフィードバックは一定です。

• ユニットテストは、常にデータに依存する生きたドキュメントとして機能します。

• 欠陥が見つかった場合、開発者はその欠陥を明らかにするためのテストを作成し、テストに合格して欠陥が修正されるようにコードを変更します。これにより、デバッグ時間が短縮されます。他のすべてのテストも実行され、それらが合格すると、既存の機能が壊れていないことが保証されます

• 開発者はいつでも設計上の決定とリファクタリングを行うことができ、テストを実行することでシステムが引き続き機能していることを確認できます。これにより、ソフトウェアが保守可能になります。

• 変更が既存の機能に影響を与える場合、テストを実行することで同じことが明らかになり、欠陥をすぐに修正できるため、開発者は変更を加える自信があります。

• 連続する各テスト実行で、以前のすべての欠陥修正も検証され、同じ欠陥の繰り返しが減少します。

• ほとんどのテストは開発中に行われるため、納品前のテストは短縮されます。

TDDのデメリット

出発点は、システムの動作を説明するユーザーストーリーです。したがって、開発者はしばしば次の質問に直面します-

• いつテストしますか？

• 何をテストしますか？

• 仕様が満たされているかどうかを知る方法は？

• コードはビジネス価値を提供しますか？

TDDに関する誤解

以下の誤解が業界に存在し、説明が必要です。

誤解	明確化
TDDは、テストとテスト自動化がすべてです。	TDDは、テストファーストアプローチを使用した開発方法論です。
TDDには設計は含まれていません。	TDDには、要件に基づいた重要な分析と設計が含まれています。デザインは開発中に現れます。
TDDはユニットレベルのみです。	TDDは、統合レベルおよびシステムレベルで使用できます。
TDDは、従来のテストプロジェクトでは使用できません。	TDDはエクストリームプログラミングで普及し、他のアジャイル手法で使用されています。ただし、従来のテストプロジェクトでも使用できます。
TDDはツールです。	TDDは開発方法論であり、新しい単体テストに合格するたびに、新しいコードが追加されたり既存のコードが変更されたりするたびに、またすべてのリファクタリング後にすべてのテストを実行する必要があるため、Automation TestSuiteに追加されます。 したがって、TDDをサポートするテスト自動化ツールはこのプロセスを容易にします。
TDDは、受け入れテストを開発者に渡すことを意味します。	TDDは、開発者に受け入れテストを渡すことを意味するものではありません。

受け入れTDD

受け入れテスト駆動開発（ATDD）は、開発の初期段階で、ユーザーストーリーの作成中に受け入れ基準と受け入れテストを定義します。ATDDは、顧客、開発者、テスター間のコミュニケーションと共通理解に重点を置いています。

ATDDの主なプラクティスは次のとおりです-

• ドメインの共通の理解を構築するために、実際のシナリオについて話し合います。

• これらのシナリオを使用して、受け入れ基準に到達します。

• 受け入れテストを自動化します。

• これらのテストに開発を集中させます。

• 変更を容易にするために、テストをライブ仕様として使用します。

ATDDを使用する利点は次のとおりです-

• 要件は明確で、機能的なギャップはありません。

• 開発者が予測する特殊なケースを理解している人もいます。

• 受け入れテストは開発をガイドします。

TDD対BDD

Dan Northによると、プログラマーは通常、テスト駆動開発の実行中に次の問題に直面します。

• どこから始めれば

• 何をテストし、何をテストしないか

• 一度にいくらテストするか

• 彼らのテストを何と呼ぶか

• テストが失敗する理由を理解する方法

これらすべての問題の解決策は、ビヘイビア駆動開発です。これは、確立されたアジャイルプラクティスから発展したものであり、アジャイルソフトウェア配信に不慣れなチームにとって、よりアクセスしやすく効果的なものにするように設計されています。時間の経過とともに、BDDは、アジャイル分析と自動受け入れテストの全体像を網羅するように成長しました。

メイン difference between TDD and BDD それは−

• TDDは、ソフトウェアがどのように機能するかを記述します。

• 一方、BDD −

  • エンドユーザーがソフトウェアをどのように使用するかを説明します。

  • コラボレーションとコミュニケーションを促進します。

  • システムの動作の例に重点を置いています。

  • 例から導き出された実行可能な仕様を目指します

TDDでは、「受け入れテスト」という用語は誤解を招く恐れがあります。受け入れテストは、実際にはシステムの予想される動作を表します。アジャイルプラクティスでは、チーム全体のコラボレーションと、顧客やその他の利害関係者とのやり取りが強調されます。そのため、プロジェクトに携わるすべての人が理解しやすい用語を使用する必要が生じています。

TDDはあなたに必要なことを考えさせます Behavior したがって、「行動」という用語は、「行動」という用語よりも有用です。 ‘Test’。BDDは、テストではなく動作に焦点を当てた語彙を備えたテスト駆動開発です。

ダン・ノースの言葉によれば、「テストでの思考から行動での思考への移行が非常に深かったので、TDDをBDDまたはビヘイビア駆動開発と呼び始めました。」TDDは何かがどのように機能するかに焦点を合わせ、BDDはなぜそれを構築するのかに焦点を合わせます。

BDDは、開発者がよく直面する次の質問に答えます-

質問	回答
どこから始めれば？	外で
何をテストしますか？	ユーザーストーリー
何をテストしないのですか？	他に何か

これらの答えは、次のようなストーリーフレームワークになります-

Story Framework

として [Role]

が欲しいです [Feature]

そのため [Benefit]

これは、 ' Feature 実行され、結果 Benefit 演奏する人に Role.'

BDDはさらに次の質問に答えます-

質問	回答
一度にいくらテストしますか？	あまり焦点を当てていない
彼らのテストを何と呼びますか？	文テンプレート
テストが失敗する理由を理解する方法	ドキュメンテーション

これらの回答により、次のようなサンプルフレームワークが作成されます。

Example Framework

Given いくつかの初期コンテキスト、

When イベントが発生し、

Then いくつかの結果を確認します。

つまり、 '最初のコンテキストから始めて、特定のイベントが発生すると、結果がどうなるかがわかります。 should be。」

したがって、この例は、システムの予想される動作を示しています。例は、システムのさまざまなシナリオを説明するために使用されます。

ストーリーとシナリオ

次のDanNorthによるATMシステムに関する図を考えてみましょう。

物語

As a お客様、

I want ATMから現金を引き出すには、

so that 銀行に並んで待つ必要はありません。

シナリオ

このストーリーには2つのシナリオが考えられます。

Scenario 1 −アカウントはクレジットされています

Given アカウントはクレジットされています

And カードは有効です

And ディスペンサーには現金が含まれています

When 顧客が現金を要求する

Then アカウントから引き落とされていることを確認します

And 現金が確実に分配されるようにする

And カードが返却されていることを確認してください

Scenario 2 −当座貸越限度額を超えて口座が引き落とされた

Given アカウントが引き落とされている

And カードは有効です

When 顧客が現金を要求する

Then 拒否メッセージが表示されていることを確認します

And 現金が支払われないようにする

And カードが返却されていることを確認してください

イベントは両方のシナリオで同じですが、コンテキストが異なります。したがって、結果は異なります。

開発サイクル

BDDの開発サイクルは outside-in アプローチ。

Step 1−赤くなる高レベル（外部）のビジネス価値の例（CucumberまたはRSpec / Capybaraを使用）を記述します。（RSpecはRuby言語でBDDフレームワークを生成します）

Step 2 −赤くなる実装の最初のステップのための低レベル（内部）のRSpecの例を書いてください。

Step 3 −その下位レベルの例に合格するための最小限のコードを実装します。緑色になるのを確認してください。

Step 4 −赤くなるステップ1の通過に向けてプッシュする次の下位レベルのRSpecの例を記述します。

Step 5 −ステップ1の高レベルの例が緑色になるまで、ステップ3とステップ4を繰り返します。

Note −以下の点に注意してください−

• Red/green stateは許可ステータスです。

• 低レベルのテストが緑色の場合、新しい例を作成したり、既存の実装をリファクタリングしたりする権限があります。リファクタリングのコンテキストでは、新しい機能/柔軟性を追加してはなりません。

• 低レベルのテストが赤の場合、既存のテストを緑にするためだけに実装コードを記述または変更する権限があります。存在しない次のテストに合格するためのコードを記述したいという衝動に抵抗するか、優れていると思われる機能を実装する必要があります（顧客は尋ねなかったでしょう）。

「SpecificationbyExample」の著者であるGojkoAdzicによると、Specification by Exampleは、ソフトウェア製品の変更を容易にして、適切な製品が効率的に提供されるようにする一連のプロセスパターンです。」

例による仕様は、抽象的なステートメントの代わりに現実的な例を使用して要件をキャプチャして説明することに基づいて、ソフトウェア製品の要件とビジネス指向の機能テストを定義するための共同アプローチです。

例による仕様–概要

例による仕様の目的は、優先順位が付けられ、検証可能なビジネス要件の開発と提供に焦点を当てることです。例による仕様の概念自体は比較的新しいものですが、それは単に既存の慣行を言い換えたものです。

ユビキタス言語として知られる非常に具体的で簡潔な語彙をサポートします。

• 実行可能要件を有効にします。

• チームの全員が使用します。

• 部門の枠を超えたチームによって作成されます。

• みんなの理解を捉えます。

例による仕様は、ビジネスドメインを反映する自動テストを構築するための直接入力として使用できます。したがって、Example by Exampleの焦点は、適切な製品の構築と製品の適切な構築にあります。

例による指定の目的

例による仕様の主な目的は、適切な製品を構築することです。理解の共有に焦点を当てているため、信頼できる唯一の情報源が確立されます。受け入れ基準の自動化が可能になるため、欠陥の検出ではなく欠陥の防止に重点を置くことができます。また、欠陥を早期に発見するための早期テストを促進します。

SbEの使用

例による仕様は、ビジネス価値を説明する予想されるシステム動作を説明するために使用されます。この図は、具体的な実例によるものです。これらの例は、次のような実行可能要件を作成するために使用されます。

• 翻訳なしでテスト可能。

• ライブドキュメントにキャプチャされます。

以下は、特定の仕様を説明するために例を使用する理由です。

• それらは理解しやすいです。

• 彼らは誤解しにくいです。

SbEの利点

例による仕様を使用する利点は次のとおりです。

• 品質の向上

• 廃棄物の削減

• 生産欠陥のリスクの低減

• 集中的な取り組み

• より安全に変更を加えることができます

• ビジネスへの関与の改善

SbEのアプリケーション

例による仕様は、-でアプリケーションを検索します

• 複雑なビジネスまたは複雑な組織。

• 純粋に技術的な問題にはうまく機能しません。

• UIに焦点を当てたソフトウェア製品ではうまく機能しません。

• レガシーシステムにも適用できます。

SbEと受け入れテスト

受け入れテストに関する例による仕様の利点は次のとおりです。

• 詳細な要件とテストの両方に1つの図が使用されます

• プロジェクトの進捗状況は、受け入れテストの観点からです-

  • 各テストは、動作をテストすることです。

  • テストは動作に合格しているか、合格していないかのどちらかです。

  • 合格テストは、特定の動作が完了したことを表します。

  • 100のビヘイビアを完了する必要があるプロジェクトで60のビヘイビアが完了した場合、60％完了します。

• テスターは欠陥修正から欠陥防止に切り替え、ソリューションの設計に貢献します。

• 自動化により、要件の変更がソリューションに与える影響を即座に理解できます。

例による仕様–さまざまな役割の意味

例による仕様の目的は、プロジェクト全体を通じて顧客を含むチームの全員のコラボレーションを促進し、ビジネス価値を提供することです。理解を深めるために、誰もが同じ語彙を使用します。

役割	SbEの使用
ビジネスアナリスト	要件は明確で、機能的なギャップはありません。 開発者は、実際に仕様を読んでください。
開発者	開発者は、何が開発されているかをよりよく理解します。 正しく開発された仕様を数えることにより、開発の進捗状況がより適切に追跡されます。
テスター	テスターは、何がテストされているかをよりよく理解します。 テスターは最初から関与し、設計に関与します。 テスターは、欠陥の検出ではなく、欠陥の防止に取り組みます。
全員	エラーを最初から特定することで時間を節約できます。 高品質の製品は最初から製造されています。

SbE –一連のプロセスパターン

この章の冒頭で見たように、「例による仕様」は、ソフトウェア製品の変更を容易にして、適切な製品が効率的に提供されるようにする一連のプロセスパターンとして定義されています。

プロセスパターンは次のとおりです。

• 共同仕様

• 例を使用した仕様の説明

• 仕様の改良

• 例の自動化

• 頻繁に検証する

• 生きている文書

共同仕様

共同仕様の目的は次のとおりです。

• チーム内のさまざまな役割を取得して、共通の理解と語彙の共有を実現します。

• 全員をプロジェクトに参加させて、機能に関するさまざまな視点を提供できるようにします。

• 機能の共有コミュニケーションと所有権を確保します。

これらの目的は、ThreeAmigosミーティングとしても知られる仕様ワークショップで達成されます。Three Amigosは、BA、QA、および開発者です。プロジェクトには他の役割もありますが、これら3つは、定義から機能の提供まで責任と説明責任を負います。

During the meeting −

• ビジネスアナリスト（BA）は、新機能の要件とテストを提示します。

• 3つのAmigos（BA、Developer、およびQA）が新機能について話し合い、仕様を確認します。

• QAと開発者は、不足している要件も特定します。

• 3つのアミーゴ

  • ユビキタス言語を使用した共有モデルを利用します。

  • ドメイン語彙を使用します（必要に応じて用語集が維持されます）。

  • 違いや矛盾を探します。

• この時点では、実装の詳細にジャンプしないでください。

• 機能が十分に指定されているかどうかについてコンセンサスを得る。

• 要件とテストの所有権を共有することで、品質仕様が容易になります

• 要件はシナリオとして提示され、明示的で明確な要件を提供します。シナリオは、ユーザーの観点から見たシステムの動作の例です。

例を使用した仕様の説明

シナリオは、Given-When-Then構造を使用して指定され、テスト可能な仕様を作成します-

Given <いくつかの前提条件>

And <追加の前提条件> Optional

When <アクション/トリガーが発生します>

Then <いくつかの事後条件>

And <追加の投稿条件> Optional

この仕様は、システムの動作の一例です。また、システムの受け入れ基準も表します。

チームは例について話し合い、例が機能の期待される動作をカバーすることに合意するまでフィードバックが組み込まれます。これにより、良好なテストカバレッジが保証されます。

仕様の改良

仕様を改良するには、

• 例を正確に書いてください。例が複雑になった場合は、より単純な例に分割してください。

• ビジネスの観点に焦点を合わせ、技術的な詳細は避けてください。

• 正と負の両方の条件を考慮してください。

• ドメイン固有の語彙に準拠します。

• 例についてお客様と話し合います。

  • これを達成するために会話を選択してください。

  • 顧客が関心を持っている例のみを検討してください。これにより、必要なコードのみを生成でき、不要な可能性のあるすべての組み合わせをカバーする必要がなくなります。

• シナリオに合格するには、そのシナリオのすべてのテストケースに合格する必要があります。したがって、仕様を拡張してテスト可能にします。テストケースには、さまざまな範囲とデータ値（境界ケースとコーナーケース）、およびデータの変更をもたらすさまざまなビジネスルールを含めることができます。

• 複雑な計算、データ操作/変換などの追加のビジネスルールを指定します。

• 例による仕様として、機能しないシナリオ（パフォーマンス、負荷、使いやすさなど）を含める

例の自動化

自動化レイヤーは非常にシンプルに保つ必要があります。テスト対象のシステムに仕様を配線するだけです。あなたは同じためのツールを使用することができます。

ドメイン固有言語（DSL）を使用してテストの自動化を実行し、入力と出力の間の明確な接続を示します。スクリプトではなく、仕様に焦点を合わせます。テストが正確で、理解しやすく、テスト可能であることを確認してください。

頻繁に検証する

すべての変更（追加/変更）で、開発パイプラインに検証例を含めます。製品の品質を確保するために採用できる（そして採用すべき）多くの技術とツールがあります。それらは3つの主要な原則を中心に展開します-Test Early, Test Well そして Test Often。

弱いリンクを特定できるように、テストを頻繁に実行してください。動作を表す例は進行状況の追跡に役立ち、動作は対応するテストに合格した後にのみ完了すると言われています。

生きているドキュメンテーション

仕様はできるだけシンプルで短くしてください。仕様を整理し、作業が進むにつれてそれらを進化させます。チームの全員がドキュメントにアクセスできるようにします。

プロセスステップの例による仕様

この図は、「例による仕様」のプロセスステップを示しています。

アンチパターン

アンチパターンは、ソフトウェア開発における特定のパターンであり、悪いプログラミング手法と見なされます。一般的な問題への一般的なアプローチであり、形式化され、一般に優れた開発手法と見なされているデザインパターンとは対照的に、アンチパターンは反対であり、望ましくありません。

アンチパターンはさまざまな問題を引き起こします。

アンチパターン	問題
コラボレーションなし	多くの仮定 間違ったものを作る 間違ったことをテストする コードが終了したときに気付かない
コードが終了したときに気付かない	テストを維持するのは難しい スペックがわかりにくい 事業担当者からの関心の喪失
詳細すぎる、またはUI中心の例	テストを維持するのは難しい 仕様がわかりにくい 事業担当者からの関心の喪失
必要な努力を過小評価する	チームは失敗したと思い、早い段階で失望します

問題の解決策-品質

アンチパターンを監視することで品質を確保できます。アンチパターンによって生じる問題を最小限に抑えるには、次のことを行う必要があります。

• 例を使用して指定するために集まります。

• 例をクリーンアップして改善します。

• 例を満たすコードを書く

• 例を自動化してデプロイします。

• すべてのユーザーストーリーに対してこのアプローチを繰り返します。

アンチパターンによる問題を解決するには、-を順守する必要があります。

• Collaboration.

• 何に焦点を当てます。

• ビジネスに焦点を当てています。

• 準備して。

上記のそれぞれが何を意味するのかを理解しましょう。

コラボレーション

共同で-

• ビジネスマン、開発者、テスターは、それぞれの視点から意見を述べます。

• 自動化された例は、チームが正しいものを構築したことを証明します。

• このプロセスは、テスト自体よりも価値があります。

何に焦点を当てる

あなたは質問に集中しなければなりません-「何」。'何'に焦点を当てながら-

• 考えられるすべてのケースを網羅しようとしないでください。

• 別の種類のテストを使用することを忘れないでください。

• 例はできるだけ単純にしてください。

• 例は、システムのユーザーが簡単に理解できるものでなければなりません。

• ツールはワークショップで重要な役割を果たすべきではありません。

ビジネスに焦点を当てる

ビジネスに集中する-

• 仕様をビジネス目的で維持します。

• 仕様の作成とレビューにビジネスを含めます。

• 自動化レイヤーのすべての詳細を非表示にします。

準備して

次のことに備えてください-

• チームのプラクティスが変更されても、メリットはすぐには明らかになりません。

• SbEの導入は困難です。

• 時間と投資が必要です。

• 自動テストは無料ではありません。

ツール

例による仕様ではツールの使用は必須ではありませんが、実際にはいくつかのツールが利用可能です。ツールを使用しなくても、例による仕様に従って成功する場合があります。

次のツールは、例による仕様をサポートしています。

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog

開発チームは、BDDがツールフレームワークであると誤解することがよくあります。実際には、BDDはツールフレームワークではなく開発アプローチです。ただし、他の開発アプローチの場合と同様に、BDD用のツールもあります。

さまざまなプラットフォームやプログラミング言語で、いくつかのBDDツールが使用されています。彼らは-

• キュウリ（Rubyフレームワーク）

• SpecFlow（.NETフレームワーク）

• 動作（Pythonフレームワーク）

• JBehave（Javaフレームワーク）

• JBehave Web（Selenium統合を備えたJavaフレームワーク）

• レタス（Pythonフレームワーク）

• Concordion（Javaフレームワーク）

• Behat（PHPフレームワーク）

• Kahlan（PHPフレームワーク）

• DaSpec（JavaScriptフレームワーク）

• ジャスミン（JavaScriptフレームワーク）

• Cucumber-js（JavaScriptフレームワーク）

• Squish GUIテスター（JavaScript、Python、Perl、Ruby、Tcl用のBDD GUIテストツール）

• Spock（Groovyフレームワーク）

• Yadda（Jasmine（JavaScriptフレームワーク）などのフレームワークに対するGherkin言語のサポート）

きゅうり

Cucumberは、グローバルに使用される実行可能仕様用の無料ツールです。Cucumberを使用すると、ソフトウェア開発チームはソフトウェアの動作をプレーンテキストで説明できます。このテキストは、ビジネスで読み取り可能なドメイン固有言語で記述されており、ドキュメント、自動テスト、開発援助として機能し、すべて1つの形式にまとめられています。Cucumberでは、40を超える異なる話し言葉（英語、中国語など）を使用できます。

きゅうり–主な機能

キュウリの主な特徴は次のとおりです-

• キュウリは、実行可能仕様、テスト自動化、およびリビングドキュメントに使用できます。

• Cucumberは、任意の言語で記述されたRuby、Java、NET、Flex、またはWebアプリケーションで動作します。

• Cucumberは、FITが行うのと同様に、テーブルでより簡潔なテストをサポートします。

• Cucumberは、要件、自動化されたテスト、およびドキュメントを、ソフトウェアを検証するプレーンテキストの実行可能仕様というまとまりのあるものに統合することで、ソフトウェア開発ライフサイクルに革命をもたらしました。

SpecFlow

SpecFlowは、.NETプラットフォーム用のBDDツールです。SpecFlowはオープンソースプロジェクトです。ソースコードはGitHubでホストされています。

SpecFlowは、機能にGherkin構文を使用します。Gherkin形式は、Cucumberによって導入され、他のツールでも使用されています。Gherkin言語は、GitHubのプロジェクトとして維持されています-https://github.com/cucumber/gherkin

振る舞う

BehaveはPythonフレームワークに使用されます。

• Behaveは、「features」と呼ばれるディレクトリに保存されている3種類のファイルで機能します-

  • 動作シナリオを含む機能ファイル。

  • シナリオのPythonステップ実装を含む「steps」ディレクトリ。

  • オプションで、いくつかの環境制御（ステップ、シナリオ、機能、または射撃試合全体の前後に実行するコード）。

• 動作機能はGherkinを使用して記述され（いくつかの変更が加えられています）、「name.feature」という名前が付けられています。

• 機能およびシナリオに添付されたタグは、それらに渡された「機能」または「シナリオ」オブジェクトを介して環境機能で使用できます。これらのオブジェクトには、「タグ」と呼ばれる属性があります。これは、機能ファイルで見つかった順序で、添付されたタグ名のリストです。

• ガーキン標準の変更-

  • Behaveは、標準のGherkinファイルを解析し、Gherkinを拡張して、小文字のステップキーワードを許可することができます。

レタス

レタスは、キュウリをベースにした非常にシンプルなBDDツールです。Pythonプロジェクトの自動テストとして、プレーンテキストの機能記述を実行できます。レタスは、BDDで最も一般的なタスクを目指しています。

コンコーディオン

Concordionは、JavaFrameworkのExampleによる仕様を自動化するためのオープンソースツールです。

コア機能はシンプルですが、強力な拡張フレームワークAPIを使用すると、Excelスプレッドシートを仕様として使用したり、スクリーンショットを出力に追加したり、ログ情報を表示したりするなどの機能を追加できます。

Concordionを使用すると、段落、表、適切な句読点を使用して通常の言語で仕様を記述でき、Given / When / Thenを使用して構造化言語を使用する必要はありません。

Concordionは、以下を含む他の言語に移植されています。

• C＃（Concordion.NET）

• Python（PyConcordion）

• ルビー（ルビー-コンコーディオン）

Cucumberは、実行可能仕様、テスト自動化、およびLivingドキュメントをサポートするツールです。

ビヘイビア駆動開発は、例による仕様を拡張します。また、テスト駆動開発のベストプラクティス、特に外部から内部への作業の観点を形式化します。開発作業は実行可能な仕様に基づいています。

ザ・ key features 実行可能な仕様は次のとおりです。

• 実行可能な仕様は次のとおりです。

  • システムの動作を表す例から派生。

  • ビジネスや利害関係者を含む、開発に関与するすべての人の協力を得て書かれています。

  • 合格基準に基づく。

• 実行可能な仕様に基づく受け入れテストは自動化されています。

• 共有されたユビキタス言語を使用して、実行可能仕様と自動テストを次のように記述します。

  • ドメイン固有の用語は、開発全体で使用されます。

  • 顧客や利害関係者を含むすべての人が、システム、その要件、およびその実装について同じように話します。

  • 同じ用語を使用して、要件、設計ドキュメント、コード、テストなどに存在するシステムについて説明します。

  • 誰でも要件と、より多くの要件を生成する方法を読んで理解できます。

  • 変更に簡単に対応できます。

  • ライブドキュメントは維持されます。

Cucumberは、実行可能仕様をシステムの実際のコードおよび自動受け入れテストと結び付けるため、このプロセスを支援します。

これを行う方法は、実際には顧客と開発者が協力するように設計されています。受け入れテストに合格すると、それが表すシステムの動作の仕様が正しく実装されたことを意味します。

典型的なキュウリ受け入れテスト

次の例を考えてみましょう。

Feature − Sign up

• サインアップは迅速かつフレンドリーでなければなりません。

• シナリオ-サインアップの成功

  • New ユーザーは確認メールを受け取り、個人的に挨拶する必要があります。

  • Given サインアップすることを選択しました。

  • When 有効な詳細でサインアップします。

  • Then 確認メールが届きます。

  • And パーソナライズされたグリーティングメッセージが表示されます。

この例から、次のことがわかります。

• 受け入れテストは Features。

• 機能はによって説明されています Scenarios。

• シナリオは Steps。

仕様はプレーンテキストファイルで自然言語で記述されていますが、実行可能です。

きゅうりの働き

Cucumberは、システムに対して実行できるシナリオを探す機能を含むテキストファイルを処理するコマンドラインツールです。きゅうりのしくみを理解しましょう。

• ファイルの名前と場所（それぞれのフォルダー）に関する一連の規則を利用して、簡単に開始できるようにします。

• Cucumberを使用すると、仕様、自動テスト、およびドキュメントを同じ場所に保管できます。

• 各シナリオは、シナリオの前提条件、アクション、および事後条件を説明するステップのリストです。各ステップがエラーなしで実行される場合、シナリオは合格としてマークされます。

• 実行の最後に、Cucumberは通過したシナリオの数を報告します。

• 何かが失敗した場合、開発者が進行できるように、何が失敗したかに関する情報を提供します。

きゅうりでは、 Features、 Scenarios、およびステップはと呼ばれる言語で書かれています Gherkin。

Gherkinは、構造を持つプレーンテキストの英語（または60以上の他の言語の1つ）です。ガーキンは習得が容易で、その構造により、簡潔な方法で例を書くことができます。

• Cucumberは、Gherkinで記述された実行可能仕様を含むファイルを実行します。

• Cucumberには、プレーンテキストのGherkinステップをシステムと対話するアクションに変換するためのステップ定義が必要です。

• Cucumberがシナリオ内のステップを実行すると、実行する一致するステップ定義が検索されます。

• ステップ定義は、パターンが付加された小さなコードです。

• このパターンは、ステップ定義を一致するすべてのステップにリンクするために使用され、コードは、CucumberがGherkinステップを検出したときに実行するものです。

• 各ステップには、ステップ定義が付属しています。

• ほとんどの手順では、入力を収集してから、フレームワークで呼び出しを行うために、アプリケーションドメインに固有のフレームワークに委任します。

Cucumberは、12を超えるさまざまなソフトウェアプラットフォームをサポートしています。自分に合ったCucumberの実装を選択できます。すべてのCucumber実装は、同じ全体的な機能を提供し、独自のインストール手順とプラットフォーム固有の機能も備えています。

ステップとステップ定義のマッピング

Cucumberの鍵は、ステップとステップ定義の間のマッピングです。

きゅうりの実装

以下に、Cucumberの実装を示します。

	Ruby / JRuby
	JRuby（Cucumber-JVMを使用）
	Java
	Groovy
	.NET（SpecFlowを使用）
	JavaScript
	JavaScript（Cucumber-JVMおよびRhinoを使用）
	Clojure
	ゴス
	ルア
	PHP（Behatを使用）
	Jython
	C ++
	Tcl

フレームワークの統合

以下にフレームワークの実装を示します。

	Ruby on Rails
	セレン
	PicoContainer
	SpringFramework
	ワティル

ガーキンは書くために使用される言語です Features, Scenarios, and Steps。Gherkinの目的は、具体的な要件の記述を支援することです。

具体的な要件の意味を理解するために、次の例を検討してください。

顧客が無効なクレジットカードの詳細を入力しないようにする必要があります。

対

顧客が正確に16桁の長さではないクレジットカード番号を入力した場合、フォームを送信しようとすると、正しい桁数を通知するエラーメッセージが表示されて再表示されます。

後者はあいまいさがなく、エラーを回避し、はるかにテスト可能です。

Gherkinは、より具体的な要件を作成するように設計されています。ガーキンでは、上記の例は次のようになります-

Feature

無効なクレジットカードの詳細を入力したときのフィードバック Feature Definition

ユーザーテストでは、ドキュメントを間違える人がたくさんいます。

Background True for all Scenarios Below

Given 購入するアイテムを選択しました、

And クレジットカード番号を入力しようとしています

Scenario −クレジットカード番号が短すぎますScenario Definition

When 16桁未満のカード番号を入力しました

And 他のすべての詳細は正しい

And フォームを送信しますSteps

Then フォームを再表示する必要があります

And 正しい桁数を通知するメッセージが表示されるはずです

Gherkinの形式と構文

Gherkinファイルはプレーンテキストファイルであり、拡張子は.featureです。空白でない各行は、Gherkinキーワードで始まり、その後に任意のテキストが続く必要があります。キーワードは−

• Feature

• Scenario

• 与えられた、いつ、そして、そして、しかし（ステップ）

• Background

• シナリオ概要

• Examples

• "" "（Doc Strings）

• | （データテーブル）

• @（タグ）

• ＃（コメント）

• *

特徴

ザ・ Featureキーワードは、ソフトウェア機能を説明し、関連するシナリオをグループ化するために使用されます。機能には3つの基本要素があります-

• キーワード–機能。

• Featureキーワードと同じ行に表示される機能の名前。

• 複数行にまたがることができるオプションの（ただし強く推奨される）説明。つまり、キーワードFeatureを含む行と、Scenario、Background、またはScenarioOutlineで始まる行の間のすべてのテキスト。

機能には、名前と説明に加えて、シナリオまたはシナリオの概要のリスト、およびオプションの背景が含まれています。

名前を付けるのが一般的です .feature機能の名前を取得し、小文字に変換し、スペースを下線に置き換えてファイルします。例えば、

feedback_when_entering_invalid_credit_card_details.feature

システム内の機能を識別するために、「機能インジェクションテンプレート」と呼ばれるものを使用できます。

<ユーザーのタイプ>として<目標を達成>するために<機能>が必要です

説明

Gherkinドキュメントの一部は、キーワードで始める必要はありません。

機能、シナリオ、シナリオの概要、または例に続く行には、キーワードで始まる行がない限り、好きなものを書くことができます。これは、説明を含める方法です。

シナリオ

システムの動作を表現するには、各機能に1つ以上のシナリオを添付します。機能ごとに5〜20のシナリオを確認して、その機能の周囲のすべての動作を完全に指定するのが一般的です。

シナリオは次のパターンに従います-

• 初期コンテキストを説明する

• イベントについて説明する

• 期待される結果を説明する

まず、コンテキストから始めて、アクションを説明し、結果を確認します。これはステップで行われます。Gherkinは、コンテキスト、アクション、および結果のそれぞれをステップとして説明する3つのキーワードを提供します。

• Given −コンテキストを確立する

• When −アクションを実行する

• Then −結果を確認する

これらのキーワードは、シナリオの読みやすさを提供します。

Example

Scenario −口座からお金を引き出します。

• Given アカウントに$ 100があります。

• When 私は$ 20を要求します。

• Then 20ドルを分配する必要があります。

複数ある場合 Given または When お互いの下のステップ、あなたは使用することができます And または But。シナリオを詳細に指定できます。

Example

Scenario −盗まれたカードを使用して引き出しを試みます。

• Given アカウントに$ 100があります。

• But 私のカードは無効です。

• When 私は50ドルを要求します。

• Then 私のカードは返却されるべきではありません。

• And 銀行に連絡するように言われるべきです。

シナリオを作成するときは、「各シナリオは意味があり、他のシナリオとは独立して実行できる必要がある」ことを忘れないでください。これは-を意味します

• あるシナリオの成功条件は、その前に他のシナリオが実行されたという事実に依存することはできません。

• 各シナリオは、特定のコンテキストを作成し、1つのことを実行して、結果をテストします。

このようなシナリオには、次の利点があります。

• テストはよりシンプルで理解しやすくなります。

• シナリオのサブセットのみを実行でき、テストセットの破損について心配する必要はありません。

• システムによっては、テストを並行して実行できる場合があり、すべてのテストの実行にかかる時間を短縮できます。

シナリオ概要

複数の入力または出力を含むシナリオを作成する必要がある場合は、値のみが異なる複数のシナリオを作成することになります。解決策は、シナリオの概要を使用することです。シナリオの概要を書くには、

• シナリオの概要ステップの変数は、<および>でマークアップされます。

• 変数のさまざまな値は、表の例として示されています。

Example

電卓で2つの数値を加算するための機能を作成しているとします。

Feature −追加。

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

シナリオの概要セクションの後には、常に、テーブルのコンテナーである例の1つ以上のセクションが続きます。テーブルには、シナリオのアウトラインステップの変数に対応するヘッダー行が必要です。以下の各行は、変数値を入力して、新しいシナリオを作成します

SpecFlowはオープンソースプロジェクトです。ソースコードはGitHubでホストされています。SpecFlowがアプリケーションの機能（ユースケース、ユーザーストーリー）の受け入れ基準を格納するために使用する機能ファイルは、Gherkin構文を使用して定義されます。

Gherkin形式は、Cucumberによって導入され、他のツールでも使用されています。Gherkin言語は、GitHubのプロジェクトとして維持されています-https://github.com/cucumber/gherkin

機能要素とSpecFlow

機能要素の主な機能は次のとおりです。

• feature要素は、機能ファイルのヘッダーを提供します。機能要素には、アプリケーションの対応する機能の名前と高レベルの説明が含まれます。

  • SpecFlowは、機能の名前から派生したクラス名を使用して、機能要素の単体テストクラスを生成します。

  • SpecFlowは、受け入れ基準を表すシナリオから実行可能な単体テストを生成します。

• 機能ファイルには、機能の受け入れテストを説明するために使用される複数のシナリオが含まれる場合があります。

  • シナリオには名前があり、複数のシナリオステップで構成できます。

  • SpecFlowは、シナリオの名前から派生したメソッド名を使用して、シナリオごとに単体テストメソッドを生成します。

複数のシナリオステップ

シナリオには、複数のシナリオステップを含めることができます。受け入れテストを構成する前提条件、アクション、または検証ステップを定義する3つのタイプのステップがあります。

• さまざまなタイプのステップは、 Given, When または Then それぞれのキーワードと同じタイプの後続のステップは、 And そして But キーワード。

• Gherkin構文では、これら3種類のステップを任意に組み合わせることができますが、シナリオには通常、 Given, When そして Then ステートメント。

• シナリオのステップはテキストを使用して定義され、DataTableと呼ばれる追加のテーブルまたはDocString引数と呼ばれる複数行のテキストを持つことができます。

• シナリオの手順は、カスタムコードを実行してアプリケーションを自動化するための主要な方法です。

• SpecFlowは、シナリオステップごとに単体テストメソッド内で呼び出しを生成します。呼び出しは、シナリオステップに一致するステップ定義を実行するSpecFlowランタイムによって実行されます。

• マッチングは実行時に行われるため、バインディングがまだ実装されていない場合でも、生成されたテストをコンパイルして実行できます。

• シナリオのステップにテーブルと複数行の引数を含めることができます。これらはステップ定義によって使用され、追加のテーブルまたは文字列引数として渡されます。

タグ

タグは、機能やシナリオに割り当てることができるマーカーです。タグを機能に割り当てることは、機能ファイル内のすべてのシナリオにタグを割り当てることと同じです。先頭に@が付いたタグ名は、タグを示します。

• 単体テストフレームワークでサポートされている場合、SpecFlowはタグからカテゴリを生成します。

• 生成されるカテゴリ名はタグの名前と同じですが、先頭に@がありません。

• これらの単体テストカテゴリを使用して、実行するテストをフィルタリングおよびグループ化できます。たとえば、重要なテストに@importantのタグを付けて、これらのテストをより頻繁に実行できます。

背景要素

背景言語要素を使用すると、機能ファイル内のすべてのシナリオに共通の前提条件を指定できます

• ファイルのバックグラウンド部分には、シナリオの他のステップの前に実行される1つ以上のシナリオステップを含めることができます。

• SpecFlowは、シナリオ用に生成されたすべての単体テストから呼び出されるバックグラウンド要素からメソッドを生成します。

シナリオの概要

シナリオの概要を使用して、データ駆動型の受け入れテストを定義できます。シナリオの概要は、常にシナリオテンプレートの仕様（<placeholder>構文を使用したデータプレースホルダーを含むシナリオ）と、プレースホルダーに値を提供する一連の例で構成されます。

• 単体テストフレームワークがそれをサポートしている場合、SpecFlowはシナリオのアウトラインから行ベースのテストを生成します。

• それ以外の場合は、シナリオの概要に対してパラメーター化された単体テストロジックメソッドを生成し、サンプルセットごとに個別の単体テストメソッドを生成します。

• トレーサビリティを向上させるために、生成された単体テストのメソッド名は、シナリオの概要のタイトルと例の最初の値（例の表の最初の列）から取得されます。

• したがって、サンプルセットの最初の列として一意で説明的なパラメータを選択することをお勧めします。

• Gherkin構文では、シナリオのアウトラインですべてのサンプル列に一致するプレースホルダーが必要なため、テストに名前を付けて読みやすくするために使用するサンプルセットに任意の列を導入することもできます。

• SpecFlowは、ステップバインディングを照合する前に、別のフェーズとしてプレースホルダー置換を実行します。

• したがって、ステップバインディングの実装とパラメータは、直接シナリオで実行されるか、シナリオアウトラインで実行されるかに依存しません。

• これにより、ステップバインディングを変更せずに、後で受け入れテストでさらに例を指定できます。

コメント

＃で行を開始することにより、任意の場所で機能ファイルにコメント行を追加できます。ただし、仕様のコメントは、受け入れ基準が誤って指定されていることを示している可能性があるため、注意してください。SpecFlowはコメント行を無視します。