ビヘイビア駆動開発

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアエンジニアリングではビヘイビア駆動開発BDD)は、ソフトウェアプロジェクトの開発者、品質保証テスター、および顧客担当者間のコラボレーションを促進するアジャイルソフトウェア開発プロセスです。[1] [2] [3]チームが会話と具体的な例を使用して、アプリケーションがどのように動作するかについての共通の理解を形式化することを奨励します。[4]テスト駆動開発(TDD)から生まれました。[1] [2] [5] [6] [漠然とした] [7]ビヘイビア駆動開発は、TDDの一般的な手法と原則を、ドメイン駆動設計オブジェクト指向分析および設計からのアイデアと組み合わせて、ソフトウェア開発および管理チームに共有ツールとソフトウェア開発で協力する共有プロセスを提供します。[2] [7]

BDDは主に、ビジネス上の利益と技術的洞察の両方によってソフトウェア開発を管理する方法についてのアイデアですが、BDDの実践では、開発プロセスをサポートするために専用のソフトウェアツールを使用することを前提としています。[5]これらのツールは、BDDプロジェクトで使用するために特別に開発されることがよくありますが、テスト駆動開発をサポートする特殊な形式のツールと見なすことができます。これらのツールは、BDDの中心的なテーマである ユビキタス言語に自動化を追加するのに役立ちます。

BDDは、動作と期待される結果を表現できる自然言語構造(英語のような文など)を使用した単純なドメイン固有言語(DSL)を使用することで大幅に促進されます。テストスクリプトは、さまざまな程度の洗練度を備えたDSLの一般的なアプリケーションとして長い間使用されてきました。BDDは、特に解決すべきビジネス上の問題の「問題領域」が複雑な場合に、効果的な技術的実践と見なされます。[8]

歴史

ビヘイビア駆動開発は、テスト駆動開発の拡張であり[9]、単純なDSLを利用する開発プロセスです。これらのDSLは、構造化自然言語ステートメントを実行可能テストに変換します。その結果、特定の機能の受け入れ基準と、その機能を検証するために使用されるテストとの関係が緊密になります。そのため、これは一般的なTDDテストの自然な拡張です。

BDDは以下に焦点を当てています:

  • プロセスのどこから始めるか
  • 何をテストし、何をテストしないか
  • 一度にテストする量
  • テストと呼ぶもの
  • テストが失敗する理由を理解する方法

BDDの本質は、自然に発生する問題を回避するために、単体テスト受け入れテストへのアプローチを再考することです。たとえば、BDDは、単体テスト名は条件付き動詞(たとえば、英語では「should」)で始まる文全体であり、ビジネス価値の順に記述する必要があることを示唆しています。受け入れテストは、ユーザーストーリーの標準的なアジャイルフレームワークを使用して作成する必要があります。受け入れ基準は、シナリオの観点から記述し、クラスに実装する必要があります。[初期コンテキスト]を指定し、[イベントが発生]すると、[いくつかの結果を保証]します。

この時点から、多くの人々が何年にもわたってBDDフレームワークを開発し、最終的には、開発者、QA、およびソフトウェアプロジェクトの非技術者またはビジネス参加者向けのコミュニケーションおよびコラボレーションフレームワークの観点からフレームワークを組み立てました。[10] 2009年11月にロンドンで開催された「アジャイル仕様、BDD、およびテスト交換」の間に、Dan North [11]はBDDについて次のように説明しました。

BDDは、第2世代、アウトサイドイン、プルベース、複数の利害関係者、複数のスケール、高自動化、アジャイル手法です。これは、明確に定義された出力との相互作用のサイクルを説明し、重要なテスト済みのソフトウェアを提供します。

2013年のGOTOConferenceでのDanNorthとのインタビューで、Liz Keogh [12]はBDDを次のように定義しました。

例を使用して、アプリケーションがどのように動作するかを説明します...そしてそれらの例について会話します。 [13]

Dan Northは、BDDフレームワークであるJBehaveを作成し、続いてRBehave [14]と呼ばれるRuby用のストーリーレベルのBDDフレームワークを作成しました。これは、後でRSpecプロジェクトに統合されました。[15]彼はまた、David Chelimsky、AslakHellesøyなどと協力してRSpecを開発し、「The RSpec Book:Behavior Driven Development with RSpec、Cucumber、andFriends」も執筆しました。RSpecの最初のストーリーベースのフレームワークは、後に主にAslakHellesøyによって開発されたCucumberに置き換えられました。Cucumberテストフレームワークの一部であるCapybaraは、そのようなWebベースのテスト自動化ソフトウェアの1つです。

BDDの原則

テスト駆動開発はソフトウェア開発方法論であり、基本的に、ソフトウェアの各ユニットについて、ソフトウェア開発者は次のことを行う必要があります。

  • 最初にユニットのテストセットを定義します;
  • テストを失敗させます。
  • 次に、ユニットを実装します。
  • 最後に、ユニットの実装によってテストが成功することを確認します。

この定義は、高レベルのソフトウェア要件、低レベルの技術的詳細、またはその間のあらゆる点でテストを可能にするという点で、かなり非特定的です。したがって、BDDを見る1つの方法は、TDDよりも具体的な選択を行うのはTDDの継続的な開発であるということです。

ビヘイビア駆動開発では、ソフトウェアの任意のユニットのテストを、ユニットの望ましい動作の観点から指定する必要があることを指定しています。[5] [7] [1]アジャイルソフトウェア開発から借りた場合、この場合の「望ましい動作」は、ビジネスによって設定された要件で構成されます。つまり、構築中のソフトウェアユニットを委託したエンティティにとってビジネス価値のある望ましい動作です。 。[5] [1] BDDの実践では、これは「アウトサイドイン」アクティビティであるBDDと呼ばれます。[16]

動作仕様

この基本的な選択に続いて、BDDによって行われる2番目の選択は、目的の動作をどのように指定するかに関するものです。この分野では、BDDは、オブジェクト指向分析および設計の分野のユーザーストーリー仕様から借用した動作仕様にセミフォーマル形式を使用することを選択しますこの形式のシナリオの側面は、状況のドメイン固有言語を使用したソフトウェアユニットの動作仕様へ のホーア論理の適用と見なすことができます。

BDDは、ビジネスアナリストと開発者がこの分野で協力し、それぞれが専用のドキュメントに明示的に記述されているユーザーストーリーの観点から動作を指定する必要があることを指定しています。[1] [16]各ユーザーストーリーは、何らかの方法で次の構造に従う必要があります。[5] [16]

タイトル
明示的なタイトル。
物語
次の構造の短い紹介セクション:
  • として:機能の恩恵を受ける人または役割。
  • 私が欲しい:機能;
  • そのため:機能の利点または価値。
合否基準
次の構造を持つ物語 の各特定のシナリオの説明:
  • 与えられた:1つ以上の節でのシナリオ開始時の初期コンテキスト。
  • いつ:シナリオをトリガーするイベント。
  • 次に:1つ以上の句で期待される結果。

BDDには、これらのユーザーストーリーを正確に書き留める方法に関する正式な要件はありませんが、BDDを使用する各チームは、上記の要素を含むユーザーストーリーを書き留めるためのシンプルで標準化された形式を考え出す必要があります。[5] [16]しかし、2007年、Dan Northは、さまざまなBDDソフトウェアツールで広く支持されているテキスト形式のテンプレートを提案しました。[16]この形式の非常に簡単な例は、次のようになります。

タイトル:返品と交換は在庫に行きます。

店舗のオーナー
として、返品や交換の際に在庫にアイテムを追加して、在庫
を追跡できるようにしたいと考えています。

シナリオ1:返金のために返品されたアイテムは、在庫に追加する必要があります。
顧客が以前に私から黒のセーターを購入し、私が在庫に黒のセーターを3つ持っていることを考えると、
彼らセーターを返品して返金する場合
私は4つの黒のセーターを在庫に入れる必要があります。

シナリオ2:交換されたアイテムは在庫に戻される必要があります。
顧客が以前に私から青い衣服を購入し、私が在庫に2つの青い衣服と3つの黒い衣服を持っていることを考えると、
彼ら青い衣服
黒い衣服に交換する
とき私は3つの青い衣服
2つの黒い衣服を持っている必要があります在庫あり。

シナリオは、対話が行われるUIの要素を参照せずに、ビジネス言語で、必須ではなく宣言的に表現されるのが理想的です。[17]

この形式はGherkin言語と呼ばれ、上記の例と同様の構文を持っています。ただし、Gherkinという用語は、 Cucumber、JBehave、Lettuce、[18] behave 、およびBehat ソフトウェアツールに固有のものです。[19] [20] [21] [22]

ユビキタス言語としての仕様

ビヘイビア駆動開発は、ドメイン駆動設計からユビキタス言語の概念を借用しています。[5] [7]ユビキタス言語は、ソフトウェア開発チームのすべてのメンバー(ソフトウェア開発者と非技術者の両方)によって共有される(セミ)フォーマル言語です。[23]問題の言語は、問題のソフトウェアのドメインを議論するための一般的な手段として、すべてのチームメンバーによって使用および開発されています。[23]このようにして、BDDはソフトウェアプロジェクトのすべての異なる役割間のコミュニケーションの手段になります。[5] [24]

ソフトウェア開発に伴う一般的なリスクには、開発者とビジネス関係者の間のコミュニケーションの崩壊が含まれます。[25] BDDは、プロジェクトチームメンバーのユビキタス言語として、望ましい動作の仕様を使用します。これが、BDDが動作仕様のためにセミフォーマル言語を主張する理由です。ある形式はユビキタス言語であるための要件です。[5]さらに、そのようなユビキタスな言語を持つことで、仕様のドメインモデルが作成されるため、仕様を正式に推論することができます。[26]このモデルは、利用可能なさまざまなBDDサポートソフトウェアツールの基礎でもあります。

上記の例は、開発中のソフトウェアシステムのユーザーストーリーを確立します。このユーザーストーリーは、利害関係者、ビジネス効果、およびビジネス価値を識別します。また、それぞれが前提条件、トリガー、および期待される結果を伴ういくつかのシナリオについても説明します。これらの各部分は、言語のより正式な部分によって正確に識別され(たとえば、 Givenという用語はキーワードと見なされる場合があります)、したがって、ユビキタス言語の正式な部分を理解するツールによって何らかの方法で処理される場合があります。

ほとんどのBDDアプリケーションは、テキストベースのDSLと仕様アプローチを使用します。ただし、統合シナリオのグラフィカルモデリングは、実際には、たとえばテスト目的でも正常に適用されています。[27]

専用工具サポート

テスト駆動開発の実践と同様に、ビヘイビア駆動開発は、プロジェクトでの特殊なサポートツールの使用を前提としています。BDDは、テストコードだけでなく、より人間が読める言語で動作を説明するための別のドキュメントを提供する必要があるため、TDDのより具体的なバージョンと見なすことができます。これには、テストの実行、説明の読み取りと解析、およびテストコードの読み取りと、実行する対応するテスト実装の検索の2段階のプロセスが必要です。このプロセスにより、BDDは開発者としての作業が少し面倒になりますが、人間が読める形式であるため、これらのドキュメントの価値は技術的な対象者にまで及んでおり、要件(「機能」)を説明するためのコミュニケーション手段として機能します。 )。

ツーリングの原則

原則として、BDDサポートツールは、TDDをサポートするツールと同様に、ソフトウェアのテストフレームワークです。ただし、TDDツールは、テストの指定が許可されている形式で非常に自由形式である傾向がある場合、BDDツールは前述のユビキタス言語の定義にリンクされています。

すでに説明したように、ユビキタス言語を使用すると、ビジネスアナリストは、開発者も理解できる方法で行動要件を書き留めることができます。BDDサポートツールの原則は、これらの同じ要件ドキュメントをテストのコレクションとして直接実行可能にすることです。仕様の実行を可能にする技術ツールに関連する理由でこれを達成できない場合は、動作要件の記述スタイルを変更するか、ツールを変更する必要があります。[28]動作要件の正確な実装はツールごとに異なりますが、アジャイルプラクティスは次の一般的なプロセスを考え出しました。

  • ツールは仕様書を読み取ります。
  • このツールは、ユビキタス言語の完全に正式な部分(上記の例のGivenキーワードなど)を直接理解します。これに基づいて、ツールは各シナリオを意味のある句に分割します。
  • シナリオ内の個々の句は、ユーザーストーリーのテスト用のある種のパラメーターに変換されます。この部分では、ソフトウェア開発者によるプロジェクト固有の作業が必要です。
  • 次に、フレームワークは、そのシナリオのパラメーターを使用して、各シナリオのテストを実行します。

Dan Northは、BDD(JBehaveおよびRBehaveを含む)をサポートする多数のフレームワークを開発しました。その操作は、ユーザーストーリーを記録するために彼が提案したテンプレートに基づいています。[5]これらのツールは、ユースケースのテキストによる説明を使用しており、他のいくつかのツール(CBehaveなど)もそれに続いています。ただし、この形式は必須ではないため、他の形式を使用する他のツールもあります。たとえば、Fitnesseデシジョンテーブルを中心に構築されています)は、BDDの展開にも使用されています。[29]

ツーリングの例

さまざまなプラットフォームやプログラミング言語向けに、今日のプロジェクトで使用されているBDDソフトウェアツールのさまざまな例がいくつかあります。

おそらく最もよく知られているのは、Dan North、ElizabethKeoghなどによって開発されたJBehaveです。[30]以下はそのプロジェクトから取られた例です:[20]

Game ofLifeの実装を検討してくださいドメインエキスパート(またはビジネスアナリスト)は、誰かがゲームグリッドの開始構成をセットアップしているときに何が起こるかを指定したい場合があります。これを行うために、彼は細胞を切り替えている人がとったいくつかのステップの例を挙げたいと思うかもしれません。物語の部分をスキップして、彼は次のシナリオをプレーンテキストドキュメント(JBehaveが読み取る入力ドキュメントのタイプ)に書き込むことによってこれを行うことができます。

5 x 5のゲーム
が与えられた場合、(3、2)でセルを切り替えると
、グリッドは次のようになります。
....。
....。
....。
..バツ..
....。
(3、1)でセルを切り替えると
、グリッドはのようになります。
....。
....。
....。
..バツ..
..バツ..
(3、2)でセルを切り替えると
、グリッドはのようになります。
....。
....。
....。
....。
..バツ..

太字の印刷は入力の一部ではありません。これは、どの単語が形式言語として認識されるかを示すためにここに含まれています。JBehaveは、Given(シナリオの開始を定義する前提条件として)、When(イベントトリガーとして)、Then(トリガーに続くアクションの結果として検証する必要がある事後条件として)という用語を認識します。これに基づいて、JBehaveはシナリオを含むテキストファイルを読み取り、解析することができますそれを節に入れます(セットアップ節と、検証可能な条件を持つ3つのイベントトリガー)。次に、JBehaveはこれらの句を受け取り、テストを設定し、イベントトリガーに応答し、結果を検証できるコードに渡します。このコードは、プロジェクトチームの開発者が作成する必要があります(Javaは、JBehaveのベースとなるプラットフォームであるため)。この場合、コードは次のようになります。

プライベート ゲーム ゲーム; 
プライベート StringRenderer レンダラー;

@Given "$ width by $ height game" 
public  void  theGameIsRunning int  width  int  height  { 
    game  =  new  Game width  height ); 
    レンダラー = 新しい StringRenderer (); 
    ゲームsetObserver レンダラー); 
}
    
@When "セルを($ column、$ row)で切り替えます" 
public  void  iToggleTheCellAt int  column  int  row  { 
    game トグルセルアット ); 
}

@Then "グリッドは$ gridのように見える必要があります" 
public  void  theGridShouldLookLike String  grid  { 
    assertThat レンダラー。asString )、equalTo グリッド)); } 

コードには、シナリオ内のすべてのタイプの句に対するメソッドがあります。JBehaveは、アノテーションを使用してどのメソッドがどの句に対応するかを識別し、シナリオの実行中に各メソッドを順番に呼び出します。シナリオの各句のテキストは、その句のコードで指定されたテンプレートテキストと一致することが期待されます(たとえば、Givenシナリオでは、「X byYゲーム」という形式の句が続くことが期待されます。JBehaveは、句とテンプレートのマッチングをサポートし、テンプレートから用語を選択して、それらをパラメーターとしてテストコードのメソッドに渡すためのサポートが組み込まれています。テストコードは、テスト対象のコードと相互作用し、シナリオに基づいてテストを実行する、シナリオ内の各句タイプの実装を提供します。この場合:

  • このメソッドは、最初のゲームグリッドを設定することにより、 GiventheGameIsRunning句に反応します。
  • このメソッドは、句で説明されているトグルイベントを発生させることにより、 When句にiToggleTheCellAt反応します。
  • このメソッドは、ゲームグリッドの状態をシナリオから予想される状態と比較することにより、 ThentheGridShouldLookLike句に反応します。

このコードの主な機能は、ストーリーを含むテキストファイルとテスト対象のコードの間のブリッジになることです。テストコードは、テスト対象のコード(この場合はのインスタンスGame)にアクセスでき、本質的に非常に単純であることに注意してください。テストコードは単純である必要があります。そうしないと、開発者は自分のテストのテストを作成する必要があります。

最後に、テストを実行するために、JBehaveは、シナリオを含み、依存関係(のインスタンスなどGame)をテストコードに注入するテキストファイルを識別する配管コードを必要とします。この配管コードは、JBehaveの技術要件であり、BDDスタイルのテストの原則に直接関係しないため、ここでは示されていません。

ストーリー対仕様

ビヘイビア駆動開発の別のサブカテゴリは、ユーザーストーリーではなく、入力言語として仕様を使用するツールによって形成されます。このスタイルの例は、 DanNorthによって最初に開発されたRSpecツールです。仕様ツールは、テストシナリオの入力形式としてユーザーストーリーを使用せず、テスト対象のユニットの機能仕様を使用します。これらの仕様は、多くの場合、ユーザーストーリーよりも技術的な性質を持っており、通常、ユーザーストーリーよりもビジネス担当者とのコミュニケーションに不便です。[5] [31]スタックの仕様の例は、次のようになります。

仕様:スタック

新しいスタックが作成された
ときそれは空です

要素がスタックに追加された
ときその要素はスタックの一番上にあります

スタックにN個の要素 
があり要素Eがスタックの一番上にある場合
ポップ操作はEを返します
スタックの新しいサイズはN-1です。

このような仕様は、テスト対象のコンポーネントの動作を正確に指定する場合がありますが、ビジネスユーザーにとってはあまり意味がありません。その結果、仕様ベースのテストは、ストーリーベースのテストを補完するものとしてBDDの実践で見られ、より低いレベルで動作します。仕様テストは、フリーフォーマットの単体テストの代わりと見なされることがよくあります。[31]

RSpecやJDaveのような仕様テストツールは、JBehaveのようなツールとは性質が多少異なります。これらはJUnitのような基本的な単体テストツールの代替と見なされているため、これらのツールはストーリーとテストコードの分離を避け、代わりにテストコードに仕様を直接埋め込むことを好む傾向があります。たとえば、ハッシュテーブルのRSpecテストは次のようになります。[32]

describe  Hash  do 
  let :hash  {  Hash [ :hello  'world' ]  }

  it  {  expect Hash .new _ to eq ({})}  

  「キーに正しい情報をハッシュする  ことを
    期待しますハッシュ[ :hello ] to  eq 'world' 
  end

   'キー を含む'ハッシュを実行します
    キー含む?:hello 真のエンドエンドである必要があります  
  

この例は、実行可能コードに埋め込まれた読み取り可能な言語での仕様を示しています。itこの場合、ツールの選択は、とという名前のメソッドを追加することにより、仕様言語をテストコードの言語に形式化することshouldです。また、仕様の前提条件の概念もあります。このbeforeセクションでは、仕様の基礎となる前提条件を確立します。

テストの結果は次のようになります。

ハッシュ
   eq {}
   キーが含まれています
   キーの正しい情報をハッシュします

3つのアミーゴ

「仕様ワークショップ」とも呼ばれる3つのアミーゴは、プロダクトオーナーが、QAや開発チームなどのさまざまな利害関係者と例による仕様の形式で要件について話し合う会議です。このディスカッションの主な目標は、会話をトリガーし、不足している仕様を特定することです。このディスカッションでは、QA、開発チーム、およびプロダクトオーナーが収束し、お互いの視点を聞いて要件を充実させ、適切な製品を構築しているかどうかを確認するためのプラットフォームも提供します。[33]

3つのアミーゴは

  • ビジネス-ビジネスユーザーの役割は、問題のみを定義することです(解決策を提案することはありません)。
  • 開発-開発者の役割には、問題を解決する方法を提案することが含まれます
  • テスト-テスターの役割は、解決策に疑問を投げかけ、What-Ifシナリオを通じてブレインストーミングのさまざまな可能性を提示し、問題を解決するための解決策をより正確にすることです。

も参照してください

参考文献

  1. ^ a b c d e North、Dan(2006年3月)。「BDDの紹介」ダンノース2019年4月25日取得
  2. ^ a bc 「 ビヘイビア 駆動開発」2015年9月1日にオリジナルからアーカイブされました2012年8月12日取得
  3. ^ Keogh、Liz(2009-09-07)。「ビヘイビア駆動開発の紹介」SkillsMatter 2019年5月1日取得
  4. ^ ジョンファーガソンスマート(2014)。動作中のBDD:ソフトウェアライフサイクル全体のビヘイビア駆動開発マニング出版物。ISBN 9781617291654
  5. ^ a b c d e f g h i j k Haring、Ronald(2011年2月)。de Ruiter、Robert(ed。)「ビヘイビア駆動開発:ベターダンテスト駆動開発」。Java Magazine(オランダ語)。Veen Magazines(1):14–17。ISSN1571-6236_ 
  6. ^ ソリス、カルロス; 王、Xiaofeng(2011)。「行動駆動開発の特徴の研究」。ソフトウェアエンジニアリングおよび高度なアプリケーション(SEAA)、2011年第37回EUROMICRO会議:383–387。土井10.1109 /SEAA.2011.76hdl10344/1256ISBN 978-1-4577-1027-8
  7. ^ a b c d Bellware、Scott(2008年6月)。「ビヘイビア駆動開発」コードマガジン2012年7月12日にオリジナルからアーカイブされました2019年5月1日取得
  8. ^ Tharayil、Ranjith(2016年2月15日)。「ビヘイビア駆動開発:複雑な問題空間の単純化」SolutionsIQ 2018年2月15日取得
  9. ^ リズキーオ(2011年6月27日)。「ATDD対BDD、およびいくつかの関連するものの鉢植えの歴史」2019年5月6日取得
  10. ^ 「RSpecブック–第11章に関する質問:重要なソフトウェアの作成」2009年11月7日にオリジナルからアーカイブされまし2009年8月9日取得
  11. ^ Dan North: BDDをビジネスに販売する方法 Archive 2010-11-25 at Wayback Machine
  12. ^ 「リズキーオ」
  13. ^ GOTO2013•LizKeogh&DanNorthへのインタビューhttps://www.youtube.com/watch?v=g5WpUJk8He4
  14. ^ D.North、RBehaveの紹介
  15. ^ S.Miller、 InfoQ:RSpecにはRBehaveが組み込まれています
  16. ^ a b c d e North、Dan(2007年2月11日)。「ストーリーの内容は?」ダンノース2012年8月12日取得
  17. ^ マベイ、ベン。「ユーザーストーリーにおける命令型シナリオと宣言型シナリオ」2010年6月3日にオリジナルからアーカイブされました2008年5月19日取得
  18. ^ 「一言で言えば—レタス0.2.23(クリプトナイトリリース)ドキュメント」lettuce.it 2020-02-06を取得
  19. ^ 「ガーキン」2020年6月7日取得
  20. ^ a b 「JBehaveとは何ですか?」JBehave.org 2015年10月20日取得
  21. ^ 「振る舞いは振る舞い駆動開発、Pythonスタイルです」2018年1月22日にオリジナルからアーカイブされました2018年1月30日取得
  22. ^ 「書き込み機能-Behat3.0.12ドキュメント」ドキュメントをbehat2015年9月19日にオリジナルからアーカイブされました2015年10月20日取得
  23. ^ a b Evans、Eric(2003)。ドメイン駆動設計:ソフトウェアの中心にある複雑さへの取り組みアディソン-ウェスリー。ISBN 978-0-321-12521-72012年8月12日取得
  24. ^ ノース、ダン(2012年5月31日)。「BDDはTDDのようなものです…」より速い組織、より速いソフトウェアダンノース&アソシエイツ2012年8月12日取得
  25. ^ Geneca(2011年3月16日)。「ソフトウェアプロジェクトが失敗する理由」2011年3月16日取得
  26. ^ Mahmudul Haque Azad(2011年2月6日)。「ビヘイビア駆動開発にこんにちは」2012年8月12日取得
  27. ^ リュブケ、ダニエル; van Lessen、Tammo(2016)。「ビヘイビア駆動開発のためのBPMNでのテストケースのモデリング」。IEEEソフトウェア33(5):15–21。土井10.1109 /MS.2016.117
  28. ^ Adam Craven(2015年9月21日)。「エンタープライズ規模のビヘイビア駆動開発(BDD)の基礎」2016年1月14日取得
  29. ^ Ketil Jensen(2009年12月13日)。「FitnessSlimのシナリオテーブルを使用したBDD」散歩を歩きます。Wordpress 2012年8月12日取得
  30. ^ "jbehave.org/team-list"JBehave。2017-05-28 2019年5月1日取得
  31. ^ a b Roy Osherove(2008年10月4日)。「BDD:動作とスペックフレームワーク」2012年8月12日取得
  32. ^ Jason Seifer(2011年12月7日)。「RSpecの概要」2012年10月27日取得
  33. ^ 「アジャイルの3つのアミーゴとは何ですか?」アジャイルアライアンス2016-06-16 2019年6月10日取得