Loading article…
動作駆動開発( BDD ) では、ドメイン言語を使用してソフトウェア テストに名前を付け、コードの動作を記述します。
BDD では、動作と予想される結果を表現できる自然言語構造 (英語のような文章など) を使用した ドメイン固有言語(DSL)が使用されます。
支持者は、BDDはソフトウェアプロジェクトにおける開発者、品質保証の専門家、顧客担当者間のコラボレーションを促進すると主張しています。[1] [2]会話や具体的な例を使用して、アプリケーションがどのように動作するかについての共通の理解を形式化することをチームに奨励します。[3] BDDは、特に問題領域が複雑な場合に効果的なプラクティスであると考えられています。[4]
BDDはテスト駆動開発（TDD）の改良版と考えられている。 [1] [5] [6] [曖昧] [7] [8] BDDはTDDの技術とドメイン駆動設計、オブジェクト指向分析設計のアイデアを組み合わせて、ソフトウェア開発チームと管理チームにソフトウェア開発の共同作業のための共有ツールと共有プロセスを提供する。[1] [7]
BDDは、高レベルでは、ビジネス上の利益と技術的洞察の両方によってソフトウェア開発を管理する方法に関するアイデアです。その実践には、専用のツールの使用が含まれます。[5] BDD専用のツールのいくつかは、TDDにも使用できます。これらのツールは、ユビキタス言語を自動化します。
概要
BDD は、DSL 構造化自然言語ステートメントを実行可能なテストに変換するプロセスです。その結果、特定の機能の受け入れ基準のように読めるテストが作成されます。
したがって、BDD は TDD の拡張です。
BDD は次のことに重点を置いています。
- プロセスのどこから始めるか
- 何をテストし、何をテストしないか
- 一度にどのくらいテストするか
- テストを何と呼ぶか
- テストが失敗する理由を理解する方法
BDD の本質は、自然に発生する問題を回避するために、自動テスト(ユニット テストと受け入れテストを含む) へのアプローチを再考することです。たとえば、BDD では、ユニット テストの名前は条件動詞 (英語では「should」など) で始まる完全な文にし、ビジネス価値の順に記述することを推奨しています。受け入れテストは、ユーザーストーリーの標準的なアジャイル フレームワークを使用して記述する必要があります。「[役割/アクター/利害関係者] として、[利点] をもたらす [機能/機能] が必要です。」受け入れ基準は、シナリオの観点から記述し、クラスに実装する必要があります。[初期コンテキスト] が与えられ、[イベントが発生] すると、[何らかの結果を確実にする]。
この時点から、多くの人々が数年にわたってBDDフレームワークを開発し、最終的にはソフトウェアプロジェクトの開発者、 QA 、非技術者やビジネス関係者のためのコミュニケーションとコラボレーションのフレームワークとしてそれを構築しました。[9]
原則
BDD では、ソフトウェア テストは望ましい動作の観点から命名されるべきであると提案されています。[5] [7]アジャイル ソフトウェア開発から借用すると、この場合の「望ましい動作」は、ビジネスによって設定された要件で構成されます。つまり、構築中のソフトウェア ユニットを委託したエンティティにとってビジネス価値がある望ましい動作です。 [5] BDD の実践では、これは BDD が「アウトサイド イン」アクティビティであると言われています。
TDD では、高レベルのソフトウェア要件、低レベルの技術的詳細、またはその間の何かに関してテストを区別しません。したがって、BDD を見る 1 つの方法は、より具体的な選択を行う TDD の進化形であるということです。
動作仕様
BDD のもう 1 つの提案は、望ましい動作をどのように指定するかに関するものです。BDD では、オブジェクト指向分析および設計の分野のユーザー ストーリー仕様から借用した、動作仕様の半形式形式を使用することを提案しています。この形式のシナリオの側面は、ドメイン固有言語を使用したソフトウェアの動作仕様への Hoare 論理の適用と見なすことができます。
BDDでは、ビジネスアナリストとソフトウェア開発者がこの分野で協力し、それぞれが明確に文書化されたユーザーストーリーに基づいて動作を指定することを提案しています。各ユーザーストーリーは、ある程度、次の構造に従う必要があります。[5]
- タイトル
- 明確なタイトル。
- 物語
- 次の構造を持つ短い導入セクション:
- として: 機能から利益を得る人物または役割。
- 欲しい機能：
- つまり、機能の利点または価値。
- 受け入れ基準
- 物語の
各特定のシナリオの説明は、次の構造になっています。
- 与えられた条件: シナリオ開始時の初期コンテキスト (1 つ以上の節内)。
- いつ: シナリオをトリガーするイベント。
- Then : 1 つ以上の節で予想される結果。
BDDでは、この情報のフォーマット方法は規定されていませんが、チームは上記の要素を含む比較的シンプルで標準化されたフォーマットを決定する必要があると示唆しています。[5]また、シナリオは命令型ではなく宣言型で表現されるべきであり、インタラクションが行われるUIの要素を参照せずにビジネス言語で表現されるべきであるとも示唆しています。[10]このフォーマットは、 CucumberではGherkin言語と呼ばれています。
ユビキタス言語としての仕様
BDD は、ドメイン駆動設計からユビキタス言語の概念を借用しています。[5] [7]ユビキタス言語は、ソフトウェア開発チームのすべてのメンバー（ソフトウェア開発者と非技術者の両方）が共有する（半）形式言語です。[11]問題の言語は、問題のソフトウェアのドメインを議論するための共通の手段として、すべてのチームメンバーによって使用および開発されています。[11]このように、BDD はソフトウェアプロジェクトのさまざまな役割間のコミュニケーションの手段になります。[5]
ソフトウェア開発における一般的なリスクとして、開発者とビジネス関係者の間のコミュニケーションが途絶えることが挙げられます。[12] BDDは、プロジェクトチームメンバーが使用するユビキタス言語として、望ましい動作の仕様を使用します。これが、BDDが動作仕様に半形式言語を要求する理由です。ユビキタス言語であるためには、ある程度の形式性が必須です。[5]さらに、このようなユビキタス言語を使用すると、仕様のドメインモデルが作成され、仕様を形式的に推論できるようになります。[13]このモデルは、利用可能なさまざまなBDD対応ソフトウェアツールの基礎でもあります。
上記の例では、開発中のソフトウェア システムのユーザー ストーリーを確立しています。このユーザー ストーリーでは、利害関係者、ビジネス効果、ビジネス価値が特定されています。また、前提条件、トリガー、および予想される結果を含む複数のシナリオも記述されています。これらの各部分は、言語のより正式な部分によって正確に識別されるため (たとえば、 Givenという用語はキーワードと見なされる場合があります)、ユビキタス言語の正式な部分を理解するツールによって何らかの方法で処理される可能性があります。
ほとんどのBDDアプリケーションではテキストベースのDSLと仕様アプローチが使用されています。しかし、統合シナリオのグラフィカルモデリングも、テスト目的などで実際に適用され、成功を収めています。[14]
特殊ツール
TDD と同様に、BDD でも特殊なツールの使用が必要になる場合があります。
BDD では、TDD と同様にテスト コードだけでなく、人間が読みやすい言語で動作を記述したドキュメントも必要です。テストの実行、記述の読み取りと解析、テスト コードの読み取りと実行するテスト実装の検索という 2 段階のプロセスが必要です。このプロセスにより、開発者にとって BDD はより面倒なものになります。BDD の支持者は、人間が読みやすいという性質により、これらのドキュメントの価値は比較的非技術的な対象者にまで及ぶため、要件 (「機能」) を記述するためのコミュニケーション手段として役立つと主張しています。
ツールの原則
原則として、BDD サポート ツールは、TDD をサポートするツールと同様に、ソフトウェアのテスト フレームワークです。ただし、TDD ツールはテストの指定に許可される形式がかなり自由であるのに対し、BDD ツールはユビキタス言語の定義にリンクされています。
ユビキタス言語により、ビジネスアナリストは開発者にも理解できる方法で動作要件を文書化できます。BDD サポート ツールの原則は、これらの同じ要件ドキュメントをテストのコレクションとして直接実行できるようにすることです。仕様の実行を可能にする技術ツールに関連する理由によりこれを実現できない場合は、動作要件の記述スタイルを変更するか、ツールを変更する必要があります。[15]動作要件の正確な実装はツールによって異なりますが、アジャイル プラクティスでは次の一般的なプロセスが考案されています。
- ツールは仕様書を読み取ります。
- ツールは、ユビキタス言語の完全に形式的な部分 (上記の例のGivenキーワードなど) を直接理解します。これに基づいて、ツールは各シナリオを意味のある節に分割します。
- シナリオ内の各節は、ユーザー ストーリーのテスト用の何らかのパラメーターに変換されます。この部分では、ソフトウェア開発者によるプロジェクト固有の作業が必要です。
- 次に、フレームワークは各シナリオのパラメータを使用して、各シナリオのテストを実行します。
ストーリーと仕様
動作駆動開発の別のサブカテゴリは、ユーザーストーリーではなく仕様を入力言語として使用するツールによって形成されます。仕様ツールは、テストシナリオの入力形式としてユーザーストーリーを使用せず、テスト対象のユニットの機能仕様を使用します。これらの仕様は、ユーザーストーリーよりも技術的な性質を持つことが多く、通常、ビジネス担当者とのコミュニケーションにはユーザーストーリーほど便利ではありません。[5] [16]スタックの仕様の例は次のようになります。
仕様:スタック 新しいスタックが作成される と、それは空になります 要素がスタックに追加される と、その要素はスタックの一番上になります スタックにN個の要素があり 、要素Eがスタックの一番上にある 場合、ポップ操作はEを返し 、スタックの新しいサイズはN-1になります。
このような仕様は、テスト対象のコンポーネントの動作を正確に指定するかもしれませんが、ビジネスユーザーにとってはあまり意味がありません。その結果、仕様ベースのテストは、BDDの実践ではストーリーベースのテストを補完するものと見なされ、より低いレベルで動作します。仕様テストは、フリーフォーマットのユニットテストの代替と見なされることがよくあります。[16]
3人の仲間
「スリーアミーゴス」は「仕様ワークショップ」とも呼ばれ、製品オーナーがQAや開発チームなどのさまざまな関係者と例を挙げて仕様の形で要件について話し合う会議です。この議論の主な目的は、会話を促し、不足している仕様を特定することです。また、この議論は、QA、開発チーム、製品オーナーが集まり、お互いの視点を聞いて要件を充実させ、適切な製品を構築しているかどうかを確認するためのプラットフォームにもなります。[17]
3人の仲間は次のとおりです。
- ビジネス - ビジネスユーザーの役割は問題を定義することだけであり、解決策を提案することではありません。
- 開発 - 開発者の役割は、問題を解決する方法を提案することです。
- テスト - テスターの役割は、ソリューションに疑問を投げかけ、what-if シナリオを通じてブレインストーミングのさまざまな可能性を提示し、問題を解決するためのソリューションをより正確にすることです。
参照
- 例による仕様
- Behat (PHP フレームワーク)
- Cynefin フレームワーク
- Concordion (Java フレームワーク)
- Rスペック
- ゲージ
- Jasmine (JavaScript テスト フレームワーク)
- Squish GUI Tester (JavaScript、Python、Perl、Ruby、Tcl 用の BDD GUI テスト ツール)
- 使用事例
- FitnesseはBDDを展開するために使用されている[18]
参考文献
- ^ abc 「Behaviour-Driven Development」。2015年9月1日時点のオリジナルよりアーカイブ。2012年8月12日閲覧。
- ^ Keogh, Liz (2009-09-07). 「行動駆動型開発入門」. SkillsMatterr . 2021-02-25時点のオリジナルよりアーカイブ。2019年5月1日閲覧。
- ^ John Ferguson Smart (2014)。BDDの実践: ソフトウェアライフサイクル全体にわたる動作駆動開発。Manning Publications。ISBN 9781617291654。
- ^ Tharayil, Ranjith (2016 年 2 月 15 日). 「行動駆動開発: 複雑な問題空間の簡素化」. SolutionsIQ . 2018 年2 月 15 日閲覧。
- ^ abcdefghij ヘリング、ロナルド (2011 年 2 月)。デ・ロイター、ロバート（編）。 「動作駆動開発: テスト駆動開発の方が優れています」。Java Magazine (オランダ語) (1)。ヴィーン マガジン: 14 ～ 17。ISSN 1571-6236。
- ^ Solis, Carlos; Wang, Xiaofeng (2011). 「行動駆動開発の特性に関する研究」。2011第 37 回 EUROMICRO ソフトウェア エンジニアリングおよび高度なアプリケーションに関する会議。pp. 383–387。doi :10.1109 / SEAA.2011.76。hdl : 10344 / 1256。ISBN 978-1-4577-1027-8. S2CID 3392536。
- ^ abcd Bellware, Scott (2008年6月). 「Behavior-Driven Development」. Code Magazine . 2012年7月12日時点のオリジナルよりアーカイブ。 2019年5月1日閲覧。
- ^ Liz Keogh (2011年6月27日). 「ATDD vs. BDD、および関連するいくつかのものの簡単な歴史」 . 2019年5月6日閲覧。
- ^ 「RSpec Book – 第 11 章「重要なソフトウェアの作成」に関する質問」。2009 年 11 月 7 日時点のオリジナルよりアーカイブ。2009 年 8 月 9 日閲覧。
- ^ Mabey, Ben. 「ユーザーストーリーにおける命令型シナリオと宣言型シナリオ」。2010年6月3日時点のオリジナルよりアーカイブ。2008年5月19日閲覧。
- ^ ab エヴァンス、エリック (2003)。ドメイン駆動設計: ソフトウェアの核となる複雑性への取り組み。Addison- Wesley。ISBN 978-0-321-12521-7. 2012年8月12日閲覧。
- ^ Geneca (2011 年 3 月 16 日). 「ソフトウェア プロジェクトが失敗する理由」 。2011年3 月 16 日閲覧。
- ^ Mahmudul Haque Azad (2011 年 2 月 6 日). 「Say Hello To Behavior Driven Development」 . 2012 年8 月 12 日閲覧。
- ^ Lübke, Daniel; van Lessen, Tammo (2016). 「ビヘイビア駆動開発のための BPMN でのテストケースのモデリング」. IEEE ソフトウェア. 33 (5): 15–21. doi :10.1109/MS.2016.117. S2CID 14539297.
- ^ Adam Craven (2015 年 9 月 21 日)。「エンタープライズ規模のビヘイビア駆動開発 (BDD) の基礎」 。2016年1 月 14 日閲覧。
- ^ ab Roy Osherove (2008 年 10 月 4 日)。「BDD: 動作フレームワークと仕様フレームワーク」。2012 年8 月 12 日閲覧。
- ^ 「アジャイルにおける3人の仲間とは?」Agile Alliance 2016年6月16日2019年6月10日閲覧。
- ^ Ketil Jensen (2009 年 12 月 13 日)。「Fitnesse Slim のシナリオ テーブルを使用した BDD」。Walk the walk。Wordpress。2012年8月 12 日閲覧。