行動プログラミング（BDD）の概要

履歴：この記事は2006年3月にBetter Software誌に初めて掲載されました。複数の言語に翻訳されています。



ある日、私は問題に遭遇しました。 開発者にさまざまなプロジェクトのTDDなどのアジャイルプログラミングプラクティスを教えると、しばしば混乱と混乱に遭遇しました。 彼らは、どこから始めて、何をテストし、何をテストしないか、一度にどれだけテストするか、テストに名前を付ける方法、テストが失敗する理由を理解する方法を知りたかったのです。



TDDを使用すればするほど、自分のスキルを磨き上げ、新しい高みに到達するのではなく、ブラインドへの動きであることに気付きました。 「ええ、もし誰かがこれを以前に私に言っていたなら！」という考えよりも、私がより頻繁に思いついたことを覚えています。「素晴らしい、道は明確です。」 TDDをトレーニングする方法を見つける必要があると判断しました。TDDをすぐに、エラーなく正しく操作する方法を示しました。



そして、この方法は振る舞いを通してプログラミングしています。 アジャイルプラクティスから生まれたもので、馴染みのないチームにとってもアクセスしやすく効果的なものになるように設計されています。 時間が経つにつれて、BDDにはアジャイル分析と自動受け入れ（ およそ受け入れ）テストが含まれるようになりました。

テスト（メソッド）の名前を文章で表現する

私の発見、喜びに満ちた「Aha！」は、同僚のクリス・スティーブンソンによって書かれた一見シンプルなユーティリティagiledoxを見せられたときに感じました。 彼女はJUnitテストを含むクラスを取り、その名前を簡単な文の形式で出力します。 そのため、テストケースは次のようになりました。

public class CustomerLookupTest extends TestCase { testFindsCustomerById() { ... } testFailsForDuplicateCustomers() { ... } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のように出力されます。

CustomerLookup

• IDで顧客を見つける
• 重複した顧客に対して失敗する
• ...

（注「CustomerLookup [顧客検索]：IDで顧客を見つけます。顧客が繰り返されるとドロップします」）



「テスト」という単語はクラス名とメソッドから削除され、ラクダ名レコードはプレーンテキストに変換されます。 彼女はそれですべてですが、効果は驚くべきものです。



開発者は、この方法でドキュメントの少なくとも一部を自分用に作成できることに気づき、テストの名前を文の形で書き留めるようになりました。 さらに、ビジネスドメインの語彙を使用してメソッド名をつづると、生成されたドキュメントがビジネスユーザー、アナリスト、テスターに​​理解できることがわかりました。

間違いなく、この簡単なテスト提供テンプレートを使用してください。

その後、興味深い文テンプレートを見つけました。これによれば、すべてのテスト名は単語will （ およそ Should）で始まる必要があります。 この文- このクラスは何かをする必要があります （ およそこのクラスは何かをします）-現在のクラスに対してのみテストを書くことができることを示唆しています。 だから、あなたは間違えられないでしょう。 このように表現できないテストを作成しようとしていることがわかった場合、明らかにこれは別のオブジェクトの動作です。



たとえば、一度、画面からの入力をチェックするクラスを作成します。 ほとんどのフィールドは、通常の顧客の詳細です：名、姓など。 しかし、その後、生年月日のフィールドと年齢のフィールドがありました。 「testShouldFailForMissingSurname」（姓がない場合はテストが失敗することに注意してください ）や「testShouldFailForMissingTitle」（タイトルがない場合はテストが失敗することに注意してください）などのメソッドを使用して、「ClientDetailsValidatorTest」（クライアントの詳細のバリデーターに注意 ）を書き始めました。



それから私は年齢の計算に困惑し、混乱するビジネスルールの世界に没頭しました：生年月日と年齢があり、それらが一致しない場合はどうなりますか？ 誕生日が今日の場合はどうなりますか？ 私がいる場合、生年月日は何歳ですか？ その後、この動作を説明するために長いテスト名を書き始めましたが、停止してすべてを移動することにしました。 そこで、「AgeCalculatorTest」（年齢計算機のおよそのテスト）で「AgeCalculator」（ およそ年齢計算機）というクラスを作成しました。 したがって、年齢を計算するためのオブジェクトの動作全体がこの計算機に移動し、「ClientDetailsValidator」は関連するテストを1つだけ必要としました-年齢計算機との正しい相互作用を確認します。



クラスが1つ以外の何かを行う場合、これは通常、この他のクラスをさらに作成する必要があることを示しています。 私はそれが何をするかを記述するインターフェースの形で新しいサービスを作成し、それをファーストクラスのコンストラクターに渡します：

 public class ClientDetailsValidator { private final AgeCalculator ageCalc; public ClientDetailsValidator(AgeCalculator ageCalc) { this.ageCalc = ageCalc; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存性注入と呼ばれるオブジェクトを一緒に作成するこのスタイルは、モックオブジェクトで特に役立ちます。

テストに明確な名前を付けてください：テストが落ちたときに助けて

しばらくして、コードを変更してテストを破ることで、コードの予想される動作を名前で明確に理解できることがわかりました。 通常、次の3つのいずれかが発生しました。

• 間違ったコードを書きました。 悪い。 解決策：コードを修正します。
• 動作は重要でしたが、どこかに移動しました。 解決策：テストを移動し、場合によっては変更します。
• 動作がtrueでなくなった：システムのタスクが変更されました。 解決策： このテストを削除します 。

後者は、理解の向上とともに、アジャイルプロジェクトでしばしば発生します。 残念ながら、TDDの初心者はテストを削除するという先天的な恐れがあります。これはコードの品質を何らかの形で低下させるかのようです。



単語のより目立たない色合いは、より正式な代替候補 （ およそ Willまたはshould）と比較すると、理解できるようになります（ およそ Should）。 これは 、テストの動作を疑うことができることを意味します。「彼は本当にそれを行うのでしょうか？」これにより、コード内のエラーによってテストが実際にクラッシュする状況と、システムの動作に関するあなたの考えがすでに間違っている状況とを区別しやすくなります。

「テスト」ではなく「行動」という言葉を使用する

そこで、「test」という単語を削除して、テストの名前ごとにその文を使用するためのツール-agiledoxができました。 それから私は、TDDを勉強するとき、人々はほとんど常に「テスト」という言葉につまずくことに気付きました。



もちろん、テストがTDDに固有ではないというのは事実ではありません。メソッドの最終セットは、コードが機能していることを確認するための良い方法です。 ただし、テストでシステムの動作が完全に記述されていない場合は、誤ったセキュリティ感覚でだまされます。



TDDを使用していたとき、「テスト」という言葉の代わりに「行動」という言葉を使用し始めました。それが適切であるだけでなく、学生からの質問はすべて魔法のように消えてしまいました。 今、私はこれらのTDDの質問のいくつかに答えました。 テストに名前を付ける最も簡単な方法は何ですか？ -これは、次の興味深い動作を説明する文です。 問題は、詳細にテストする方法ですか？ 純粋に理論的になります：文が許す限りの動作のみを記述できます。 テストが失敗した場合の対処方法 -上記の手順に従ってください：バグを作成したか、動作が移動したか、テストが不要になりました。



テストよりも行動で考えることは非常に有益であることがわかったので、行動またはBDDを介してTDDテストと呼び始めました。

JBehaveはテストではなく動作に焦点を当てています

2003年の終わりに向かって、私は今話していることにお金を、あるいは少なくとも私の時間を投資する時であると決めました。 JUnit-JBehaveに代わるものを書き始めました。 その中にテストへの言及はありませんでした;彼はテストされた振る舞いを中心に構築された語彙に置き換えました。 このすべては、動作を介したテストに関する新しいマントラを厳密に遵守した場合に、このようなフレームワークがどのように進化するかを調べるためです。 また、このツールは、単語テストから派生した単語の注意をそらすことなくTDDとBDDを教えるのに役立つと思いました。



架空の「CustomerLookup」（ およその顧客検索）クラスの動作を定義するには、たとえば「CustomerLookupBehavior」（ およその顧客検索動作）と呼ばれる動作のクラスを作成します。 「will」という単語で始まるメソッドが含まれます（ 注意が必要です）。 JUnitがテスト用に行うように、動作チェック（ およそ動作ランナー）を開始するプログラムは、この動作クラスを作成し、動作を順番に記述する各メソッドを呼び出します。 その後、彼女は処刑の進行状況について報告し、最後に結果を出さなければなりません。



私の最初の目標は、JBehaveに自分自身をテストさせることでした。 このプログラムがそれ自体を実行できるようにする動作を追加しました。 すべてのJUnitテストをJBehaveの動作に転送し、JUnitと同じフィードバックを得ることができました。

次の最も重要な動作を特定します

JBehaveを使用したこれらの実験の直後に、ビジネス価値の概念を理解し始めました。 もちろん、私は何かのためにコードを書いていることを常に知っていましたが、今書いたコードの重要性については考えませんでした。 私の同僚であるビジネスアナリストのクリスマットは、行動によるテストのコンテキストにおけるビジネスの関連性について考えるように促しました。



この目標を念頭に置いて-JBehaveのセルフテストを行うには、より簡単に焦点を合わせるために、 「システムが実行しない次の最も重要なことは何ですか？」



この質問では、まだ実装していない機能の重要性を判断し、優先順位を付ける必要があります。 また、振る舞いを記述するメソッドの名前を定式化するのに役立ちます。システムはX（Xは明確な振る舞いです）ではなく、Xは重要です。 これは、システムがXを実行することを意味するため、次の動作方法は次のようになります。

 public void shouldDoX() { // ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、TDDについての質問、つまりどこから始めればいいのかという答えが得られました。

要件も行動です

私の手にはフレームワークがあり、TDDの仕組みを理解し、さらに重要なこととして、発見したすべての落とし穴から私を救ったアプローチを説明しました。



2004年の終わり頃、私はかつてマツに対して発見した行動ベースのアプローチについて説明し、「しかし、これはまさに分析に似ています」と述べました。 そして、熟考のために一時停止した後、このすべての行動ベースの思考を適用して要件を決定することにしました。 したがって、アナリスト、テスター、開発者、およびビジネス向けの便利な語彙を開発できれば、技術者がビジネスの人々と話すときに生じる不確実性と誤解を排除するための正しい道を歩むことができます。

BDDは分析のための「すべての言語に開かれた」を提供します

この頃、エリック・エヴァンスは、エリック・エヴァンスによるベストセラーのドメイン駆動設計を出版しました。 その中で、ビジネス用語に直接コードを浸透させるために、ビジネスモデルに基づいて、誰もがアクセスできる言語を使用してシステムをモデル化する概念について説明しています。



クリスと私は、分析プロセス自体のために誰もがアクセスできる言語を決定しようとしていることに気付きました！ 良いスタートが切れました。 一般に、当社にはすでに次のようなユーザーストーリーのテンプレートがあります。

[X] として

欲しい [Y]

[Z]

（ 約 Xであるため、Yが必要なので、Zがどうなりますか。 ）



ここで、Yは何らかの機能、Zはこの機能のメリットまたは価値、Xはメリットのある人（または役割）です。 この提案の利点は、最初の定義の間に開発中のストーリーの重要性を判断することを強制することです。 結局のところ、実際のビジネス上の重要性の歴史がない場合、次のような低下が起こります。「... [ある機能]が必要です。だからこそ[私はそれをやる、それでいいのですか？]」 」 私たちの方法により、これらのかなり難解な要件を検証の範囲を超えて取ることができます。



そして最初から、Mattsと私は、すべてのアジャイルテスターがすでに知っていることを発見する道を歩んでいました。ユーザーストーリーの動作は単なる受け入れ基準です。つまり、システムがすべての受け入れ基準を満たしている場合、その動作は真です。 そうでない場合は、いいえ。 そのため、ユーザーストーリーを評価するための基準を記録するための提案テンプレートを作成しました。



このテンプレートは、アナリストが制限や不自然さを感じない程度にシンプルである必要がありますが、ストーリーをコンポーネントフラグメントに分割して自動化できるように順序付けられている必要があります。 したがって、 スクリプトの概念を使用して受け入れ基準を説明しました。これは次の形式を取りました。

（ おおよそ -与えられた）コンテキストを持っている、

イベントが発生したとき （ およそ ）、

次に （ 約 ）結果を確認します。

これを実証するために、古典的なATMの例を使用しましょう。 ストーリーカードの1つは次のようになります。

+名前：顧客は現金を引き出します+

顧客として

ATMからお金を引き出したい

ですから 、銀行で並んで待つ必要はありません。

さて、物語が終わったことをどのように理解しますか？ いくつかのシナリオがあります。口座にお金があります。 アカウントにお金はありませんが、当座借越内で引き出すことができます。 スコアが当座貸越を超えました。 もちろん、他のシナリオもあります。この引き出しが正確に当座貸越であるか、ATMにお金がありません。



Have-When-Thenパターンを使用すると、最初の2つのシナリオは次のようになります。

シナリオ1：アカウントにお金があります+

お金でアカウントを持っている

そして有効なカード

そして現金付きATM

顧客が現金を要求するとき

次に 、口座から引き落とされたことを確認します

そして 、現金が発行されていることを確認してください

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

ユニオンを使用し、いくつかの初期条件（ 約指定 ）と結果（ 約指定 ）を組み合わせることで理解が容易になることに注意してください。

+シナリオ2：引き出しが当座貸越を超えている+

制限を超えるアカウントを持っている

そして有効なカード

顧客が現金を要求するとき

次に 、失敗メッセージが表示されていることを確認します

そして 、現金が発行されていないことを確認してください

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

両方のシナリオは同じイベントに基づいており、いくつかの一般的なベースライン条件と結果さえあります。 ベースラインの条件、イベント、および結果を再利用することで、この恩恵を受けることができます。

受け入れ基準を実行可能にする

このシナリオのフラグメント（ベースライン、イベント、および結果）は、プログラムするのに十分なほど小さくなっています。 JBehaveには、スクリプトフラグメントをJavaクラスと明示的に関連付けることができるオブジェクトモデルがあります。



次のように、各初期条件（ おおよそ指定された ）を表すクラスを記述します。

 public class AccountIsInCredit implements Given { public void setup(World world) { ... } } public class CardIsValid implements Given { public void setup(World world) { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのイベントの1つは次のようになります。

 public class CustomerRequestsCash implements Event { public void occurIn(World world) { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトの結果についても同様です。 JBehaveはそれをすべて結び付けて実行します。 オブジェクトを保存するためのどこかに存在する「ワールド」を作成し、JBehaveがそれを各初期条件（おおよそ）に順番に渡し、既知の状態でワールドを初期化できるようにします。 JBehaveは、特定のシナリオの宣言された動作を実行するこの世界での「発生」イベントを要求します。 そして最後に、JBehaveは特定のストーリーで定義した結果に制御を移します。



スクリプトの各フラグメントを表すクラスにより、フラグメントを他のスクリプトまたはストーリーに再利用できます。 まず、これらのフラグメントは、モックオブジェクトを使用して実装され、口座にお金を設定したり、有効性カードを設定したりします。これが、動作の実装の基盤を作成する方法です。 特定のアプリケーションを実装すると、初期条件と結果が変わり、作成した実際のクラスの使用が開始されるため、スクリプトが完了するまでに、それらは最初から最後まで真の機能テストになります。

BDDの現在と未来

しばらくして、JBehaveは再び活発に開発を進めています。 そのコアは非常に完成しており、信頼性があります。 次のステップは、IntelliJ IDEAやEclipseなどの一般的なJava IDEとの統合です。



Dave Astelは最近BDDを積極的に推進しています。 彼のブログとさまざまな出版された記事は、活発な活動を引き起こしました。 最も注目すべきは、RubyでBDDフレームワークを作成するためのrspecプロジェクトです。 RubyでJBehaveを実装するrbehaveの作業を開始しました。



私の同僚は、さまざまな実際のプロジェクトでBDD技術を使用した後、この方法が大成功であると報告しました。 ストーリーを実行するためのJBehaveサブルーチン（受け入れ基準を確認する部分）は、積極的に開発されています。



将来的には、ビジネスアナリストとテスターが通常のテキストエディターでストーリーを記述し、すべてビジネスモデルの言語で動作クラスのスタブオブジェクトを作成できるようにするフルサークルエディターが必要です。 BDDは多くの人々の助けを借りて進化してきました。私は彼らに深い感謝の意を表します。



ご注意 ダンノースは、アジャイル開発方法論の教授です。 ソフトウェアを開発し、約20年間これを教えます。 彼自身のコンサルティングおよびソフトウェア開発機関の作成者。 行動による開発（BDD）の概念を導入しました。