The All-New Range Rover | Test & DevelopmentThe All-New Range Rover | Test & Development / landrovermena

  • 十分といったら十分
  • ステークホルダーに価値をもたらす
  • すべては振る舞いから

構成

詳細

ビヘイビア駆動開発(BDD)とは

テスト駆動開発(TDD)からビヘイビア駆動開発(BDD)へ

TDD・・・オブジェクトが何をするかではなく、オブジェクトが何であるか。構造に焦点を合わせる。

TDD

TDD概念図

BDD・・・オブジェクトが何をするか。構造ではなく振る舞いに焦点を合わせる。

BDD

BDD概念図

BDDの概要

BDDとは、ステークホルダーの視点に立って振る舞いを説明することにより、アプリケーションを実装するための手法である。

『The RSpec Book』

BDDサイクル

  1. Cucmberで始める
  2. 1つのシナリオに焦点を合わせる
  3. 失敗するステップ定義を書く
  4. RSpecに進む
    1. 失敗するサンプルを書く
    2. サンプルを失敗させる
    3. リファクタリング
    4. ステップが成功するまで1-3を繰り返す
  5. リファクタリング
  6. シナリオが成功するまで1-5を繰り返す
  7. シナリオが成功したら1に戻る

BDDの原則

  • 十分といったら十分
  • ステークホルダーに価値をもたらす
  • すべては振る舞いから

プロジェクトのインセプション

  1. すべてのステークホルダーを集めて、プロジェクトのビジョンまたは目的を定める。
  2. 定めたことを理解するためそのビジョンを持つコアステークホルダーと協力し、結果または目標を洗い出す。洗い出す対象はSMARTであることが望ましい。
  3. 洗いだしたことを達成するソフトウエアで実行する必要があることを、フィーチャーセットまたはテーマ(レポートや顧客の登録など)として表現する。
  4. 最後にこれらのテーマを構成する特定のフィーチャやストーリーについて話し合う

BDDは主にこの最後のレベルで適用される。また、ステークホルダーやビジネスアナリストといった用語は、個人ではなく役割を表す。

SMARTな結果

SMARTは、ある種の特性を持つ結果または目標を表現するために使われる頭文字です。その特性とは、Specific(具体的)、Measurable(測定可能)、Achievable(達成可能)、Relevant(適切)、Timeboxed(期限付き)の5つです。

『The RSpec Book』

リリースサイクル

  1. ステークホルダーがビジネスアナリストと話し合い要件をフィーチャとして表現する。必要があればフィーチャを検証可能な小さなストーリーに分解する。
  2. ステークホルダーとビジネスアナリストがテスト担当者と協力してストーリーの範囲を決定する。各ストーリーはどのように完結するかを意識する。
  3. プログラマがストーリーの実装にとりかかる前の最後のタスクとして必要に応じてシナリオを自動化する。
  4. 開発者はRSpecと「Coding by Example」に基づいてシナリオを実際に動かす。
  5. 必要な振る舞いを説明するサンプルコードを記述する
  6. そのサンプルを動作させるためのコードを実装する
  7. リファクタリングをおこなう
  8. このシナリオを動かすのに十分なソフトウエアを完成させ、他のシナリオが動くようになるまでこの作業を繰り返す。
  9. 一周して元に戻り、実際に動くシナリオをステークホルダーに見てもらいストーリーを完成させる。

BDDのもっとも重要な特徴の1つはシナリオを自動化するのが簡単で、しかもステークホルダーにとって理解しやすいこと。 これらのシナリオを定義し、自動化するのがCucumberが担当する。

ストーリーイン、フィーチャアウト

フィーチャは凝集された価値をステークホルダーに提供するものであり、ストーリーはほんの数日で実装できる機能を見てもらうためのものです。 したがって、ステークホルダーにとって意味があるのはフィーチャのほうであり、フィーチャを提供するチームにとって意味があるのはストーリーのほうです。

『The RSpec Book』

BDD_01

ストーリーの構造

  • タイトル
    どのストーリーについて説明するのかを明確にする。
  • ナラティブ
    最低でもこのストーリーのステークホルダー、ステークホルダーが望んでいるフィーチャの説明、およびステークホルダーがそれを望んでいる理由を明らかにする。そしてこの振る舞いによりどのような利益を手にするのかを明らかにする。
  • 受け入れ基準
    BDDの受け入れ基準は個々のステップで構成されるいくつかのシナリオとして定義される。

ナラティブの例

1
2
3
<ステークホルダー>として
<フィーチャ>をしたい
なぜなら<利益>だからだ
  • ビジネスアナリストはステークホルダーの使う言葉(ドメイン用語)をストーリーに使うことで全員が同じ用語を使うようにしなければならない
  • ドメイン用語はオブジェクト、メソッド、変数などコードベースにそのまま含まれる
  • ストーリーの「完了」を定義する受け入れい基準となるシナリオにおいて重要なのはステークホルダーが行うのとまったく同じ方法でアプリケーションとやりとりすること

まとめ

  • BDDはTDDの枠組みを変化させ、本格的なアジャイル開発を理解しやすくする試みから発展した手法。
  • BDDには3つの原則がある

    • 十分といったら十分
    • ステークホルダーに価値をもたらす
    • すべては振る舞いから
  • BDDのストーリーとシナリオは、自動化しやすく、ステークホルダーが明確に理解できることに重点を置いてた上で、一連の作業モデルをサポートするように設計されている。

実装例

ビヘイビア駆動開発入門を参照

参考文献