はじめに
レバレジーズ株式会社でフロントエンドエンジニアとして勤めている森山です。
今回は振る舞い駆動開発（Behavior Driven Development、通称BDD）をご紹介します。
ここでの振る舞い駆動開発とはDan North氏が提唱しているBDDの要点を掴み、自チーム流に昇華させたものです。
振る舞い駆動開発を導入して最も良かったことは、アジャイルにおいても開発スピードを保ちつつ一定の品質を担保できたことです。
一定の品質というのは機能適合性が担保されているということです。
また振る舞い駆動開発をすすめていく中で副次的に開発者のプロダクトへの理解度や視座が高まり、より良いプロダクトを作ろうという意思が一人ひとりに芽生えたと感じています。
概要
振る舞い駆動開発の目的は以下です。
振る舞い駆動開発の手順は以下になります。
ユビキタス言語の定義
ユーザーストーリーの定義
ユースケースの定義
テストケースの定義
プロダクト実装
テスト実装
振る舞い駆動開発ってなに？
そもそも私が振る舞い駆動開発をどう定義しているのか説明します。
観点としては以下になります。
目的はなに？
振る舞い駆動開発ってなに？
テスト駆動開発とは何か違うの？
振る舞いってなに？
目的はなに？
開発スピードを維持しながら一定の品質担保です。
振る舞い駆動開発ってなに？
端的に言うと「システムの振る舞いに焦点を当てたテスト駆動開発」です。
テスト駆動開発とは何が違うの？
テストの対象が異なります。
イメージとしては、テスト駆動開発よりも振る舞い駆動開発の方がテスト粒度が荒く、網羅性が低いです。
一方、テスト対象以外はテスト駆動開発と振る舞い駆動開発もテストファーストな開発手法としては同じです。
テストファーストとある通りテストコードを先に書いてから、
テストファーストは以下のメリットがあります。
ただテストファーストな開発はメリットだけではないと思っています。
以下のような難点も存在します。
プロダクトコードのみを書く場合よりも開発が遅い。
テストすべき内容や粒度をどのように判断するのか難しい。
仕様が変更された時の影響が大きい。
上記はウォーターフォール開発であればさほど目立ちません。
しかし上記の難点は、アジャイルな開発だと顕著になります。
スプリント期間内でアウトプットを出す難易度が高い。
機能毎にテストの粒度を判断するコストが高い。
仕様変更による手戻りの影響範囲が大きい。
プロダクトコードと合わせてテストコードも書く必要があるので、短期的に見ると開発スピードは落ちます。
またテストはどの粒度で定義するのかという迷いも生じます。
さらに手戻りが発生した時の影響範囲も大きいです。
とはいえテストファーストで一定の品質を保ちつつ開発者のシステム要件の理解度を上げていきたいので、アジャイルで開発しつつもテスト駆動開発の旨味を享受するためにテスト対象として「振る舞い」に着目します。
振る舞いってなに？
振る舞いとは、ユーザに価値を提供できるシステムの動きです。
極端な例ですがECサイトを考えます。
「商品をカートに入れる」ことができれば、ボタンの連打制御は無くてもいいです。
またこれは私の持論ですが、困りごとが解決できる手段があれば多少使い勝手が悪くても嬉しいです。
ソフトウェアが提供する価値の種類にもよるので一概にも言えませんが、アジャイルな開発で求められるソフトウェアは上記がほぼ当てはまるのかなと思っています。
ただ単純にテストという言葉に引っ張られると大抵「xxxであるべき」という文言を使って理想状態を定義します。
開発者としても「システムとしてあるべき状態を担保するテストを書け」と言われると際限がないように思えます。
もう一度、この章の冒頭の言葉を引用すると「振る舞いとは、ユーザに価値を提供できるシステムの動き」です。
また「振る舞い」はコード上ではシステマチックに定義されます。
振る舞いひとつの構成は以下です。
Given: システムがこの状態の時に
When: この動作をすると
Then: システムはこう振る舞う
詳しくは後述しますが、振る舞いは1つのユーザーの1つのアクションに対してシステムがどう動くのかを定義します。
振る舞い駆動開発の手順
振る舞い駆動開発の手順は以下になります。
ユビキタス言語の定義
ユーザーストーリーの定義
ユースケースの定義
テストケースの定義
プロダクト実装
テスト実装
上記の手順が生まれた背景・思考プロセスはざっくり以下です。
一定の品質を保ちながら開発をすすめるためにテストファーストな開発をしたいな。
テストファーストな開発をするためには、何をテストすべきか決まっている必要があるな。
何をテストすべきか決めるにはシステムがユーザーに提供したい価値や手段を明確にする必要があるな。
ユーザーに提供したい価値を明確にするためにはユーザーストーリー、ユースケースの定義が必要だな。
ユーザストーリーやユースケースを開発者やPDM等、誰が読んでも一律同じ解釈ができるためにはユビキタス言語の定義が必要だ。
上記の背景・思考プロセスを逆転させて振る舞い駆動開発の手順となっています。
次章から各手順でどんなことをしているのか説明します。
ユビキタス言語の定義
ユビキタス言語とは
開発者やPDMを含むチーム全体の共通言語のことです。
例えば、会社を表現する時にそのまま「会社」という表現を使うのか、「企業」という表現を使うのかをチームの中で決めておくということです。
またプロジェクト独自の概念や造語も含まれます。
ユビキタス言語を定義する目的
目的は以下の3つです。
コードやドキュメントを誰が読んでも一律同じ解釈ができる状態にすること
システム上での表記揺れを無くすこと
新規参入者のオンボーディング
ユビキタス言語の定義方法
定義方法は簡単で、テーブル形式で記載しています。
ドキュメント
類義語
プログラム単数
プログラム複数
意味
企業
会社、組織
corporation
corporations
利益を得ることを目的にして事業を行う組織体のこと。
引き直し
再登録
paymentReload
-
サブスクリプションサービスを解約していた人が再契約した時に決済予定が記録されること。
各カラムについて説明します。
ドキュメント
開発者やPdMが会話上やドキュメント上で活用していく表現です。
類義語
端的に言うとNGワードのような扱いです。
プログラム（単数/複数）
コード上で変数名やテーブルのカラム名として活用されます。
念の為複数形も定義しておくと良いです。
意味
その単語の意味です。
ユビキタス言語の恩恵
ユビキタス言語の恩恵としては、コードやドキュメント上で顕著に発揮されています。
特にコード上で、企業idをフロントエンドではcorporationIdと定義しているのに、バックエンドではcompanyIdという命名で定義しているというような場面を稀に見かけます。
これの悪いところは、変数名を変更するという改修が顧客に対して価値を生み出さないところです。
ユビキタス言語は新規開発者のオンボーディングでも役に立ちます。
ユーザーストーリーの定義
ユーザーストーリーとは
ユーザーストーリーとは、ユーザーができるようになりたいことをまとめたものです。
システムが何を提供すべきかではなく、ユーザーが何をしたいかに焦点を当てます。
ユーザーストーリーの目的
ユーザーストーリーの目的は開発するシステムに引っ張られずにユーザーに提供したい価値を見える化することです。
ユーザーストーリーがあることで開発者は「振る舞い」を実装・テストする際にそもそもその振る舞いは何を実現したいのか？を見極め自分自身でシステムとして適切な機能なのか有効なテストなのか判断できます。
ユーザーストーリーの構成
ユーザーストーリーは以下の要素から構成されています。
それぞれ何を意味するのか説明します。
アクター
エピック
ユーザーストーリー
ユーザーストーリーの具体例
例としてフリマサイトのユーザーストーリーを書いてみます。
アクター
エピック
出品者は、商品を出品する。
購入者は、商品を検索する。
購入者は、商品の詳細を確認する。
購入者は、商品をお気に入り登録する。
購入者は、商品を購入する。
ユーザーストーリー
出品者は、商品を出品する。
出品者は、出品する商品の画像をアップロードする。
なぜなら、商品がどんな商品なのか購入者に画像で知らせたいから。
出品者は、出品する商品の価格を設定する。
出品者は、出品する商品の詳細情報を設定する。
なぜなら、商品の画像で伝わらない商品の情報を購入者に伝えたいから。
出品者は、商品の出品を完了する。
出品者は、自身の出品リストを確認する。
なぜなら、先ほど出品した商品が出品できているか確認したいから。
なぜなら、出品した商品の設定内容に誤りが無いか再確認したいから。
購入者は、商品を検索する。
上記のように箇条書きで羅列する形式でユーザーストーリーを書いています。
ユーザーストーリーの定義方法
定義方法の要点は3点あります。
フォーマット
行動はシステムを介さないユーザー視点
いきなりユーザーストーリーを書かない
1.フォーマット
ユーザーのニーズと背景が必ず一対一もしくは一対多で紐付く形式にするためです。
2.行動はシステムを介さないユーザー視点
また場合によってはシステムが介入しないユーザーストーリーも存在しえます。
3.いきなりユーザーストーリーを書かない
ユースケースの定義
ユースケースとは
ユースケースとは、端的に言うとユーザーストーリーを具体化したものです。
ユースケースの目的
ユースケースの目的は、ユーザストーリーを実現するための画面上での遷移や操作を表現することです。
単にシステムがどう振る舞うかのドキュメントではなく、「ユーザーストーリーを実現するための」というところが重要です。
ユースケースの構成
ユースケースは以下の要素から構成されています。
それぞれ何を意味するのか説明します。
アクター
エピック
ユースケース
ユースケースは箇条書きで記載しています。
ユースケースの具体例
例としてフリマサイトのユースケースを書いてみます。
アクター
エピック
出品者は、商品を出品する。
購入者は、商品を検索する。
購入者は、商品の詳細を確認する。
購入者は、商品をお気に入り登録する。
購入者は、商品を購入する。
ユースケース
出品者は、商品を出品する。
出品者は、フリマアプリにアクセスする。
出品者は、ログイン情報を入力する。
出品者は、「出品ボタン」をクリックする。
出品者は、「商品の画像アップロードボタン」をクリックする。
出品者は、出品したい画像を選択する。
出品者は、商品の価格に3000と入力する。
システムは、商品の価格を3000と表示する。
システムは、商品の手数料を300と表示する。
…etc
購入者は、商品を検索する。
上記のように箇条書きで羅列する形式でユースケースを書いています。
ユースケースの定義方法
定義方法の要点は3点あります。
フォーマット
ユーザーストーリーと紐ついていること
ケースの網羅は不要
1.フォーマット
2.ユーザーストーリーと紐ついていること
基本的にユースケースは何かしらのユーザーストーリーと一対一で紐ついています。
3.ケースの網羅は不要
基本的にユーザーストーリーを実現する手段は細かく見ると複数存在します。
デバイスのカメラを起動して撮影してアップロード
OSのファイルシステムを起動してアップロード
ドラッグ&ドロップでアップロード
ユースケースはユーザーストーリーを実現するための詳細な挙動なので3パターンのユースケースが想定できますが、
テストの定義
テストケースとは
ここでのテストケースとは、振る舞いをシステマチックにテストケース化したものです。
振る舞いはユースケースの一つ一つから以下のようなフォーマットで作成されます。
Given: システムがこの状態の時に
When: この動作をすると
Then: システムはこう振る舞う
上記の様にGherkin記法と呼ばれる書き方で記載します。
Given = 前提条件
When = ユーザーのシステムに対する動作
Then = ユーザーの動作に対するシステムの挙動
Given、When、ThenのそれぞれをStepと呼びます。
そして1つのユースケースが1つのScenarioとしてテストケース化されます。
テストケースの具体例
テストケースの具体例としては以下になります。
Feature: 商品の出品
Background: 前提条件
Given ログインしていること
Scenario: 出品の開始
Given トップページにアクセスしていること
When 「出品」ボタンをクリック
Then 商品の出品画面に遷移していること
Scenario: 商品価格の入力
Given 商品の出品画面にアクセスしていること
When 商品の価格フォームに3000と入力
Then 商品の価格が3000と表示されていること
* 商品の手数料が300と表示されていること
Scenario: 商品詳細の入力...
Gherkinではまず上記の様にFeatureとしてユースケースのエピックに該当する大項目を記載します。
そこから各Scenarioを列挙していきます。
テストの実装
Gherkin記法で定義したテストケースに紐付くテストを実装していきます。
テストの実装自体はCypressを用いた実装になりますが、CCPの関数を間に挟むことでテストケースと紐付くテストが存在していることを機械的に担保できるようになります。
例として、先ほどのユースケースに紐付くテストを書くと以下になります。
import { Given ,When, Then } from '@badeball/cypress-cucumber-preprocessor' ;
Given("ログインしていること" ,()=>{
cy.login();
} );
Given("トップページにアクセスしていること" ,()=>{
cy.visit("http://toppage" )
} );
When("「出品」ボタンをクリック" ,()=>{
cy.get('[data-cy="ExhabitButton"]' ).click();
} );
Then("商品の出品画面に遷移していること" ,()=>{
cy.url().should("equal" , "http://exhabit" );
} );
CCPは、各Step（Given、When、Then）の関数を提供してくれています。
各Step関数の中では、Cypressのテスト関数がそのまま使えるので対応するユーザーのアクションを定義していきます。
テストファイル内での各Step関数の第一引数はGherkinファイルで定義した各Stepの内容と完全一致している必要があります。
CCPのアルゴリズムとしては、まずテストケースの中身を上から順番に読み込みます。
以下は「商品の出品画面に遷移していること」というテストが存在しなかった時のerrorです。
サジェストにあるように”pending”という文字列をStep関数で返却するとテストをスキップすることができます。
Then(("商品の出品画面に遷移していること" )=>{
return "pending" ;
} );
テスト結果ではPendingの件数が表示されます。
振る舞い駆動開発の恩恵
最も実感しやすかった恩恵は実装スピードを落とさずに一定の品質を担保できているところです。
元々は、開発者とPdMの目線があっていないことが原因で手戻りが発生していました。
しかし以下がシステマチックに管理されることでその手戻りは激減しました。
システムはどう振る舞うべきか？
その振る舞いはユーザーにどんな価値を提供するのか？
またテストの実装漏れも少なくなり、実装段階から品質を担保することができるようになりました。
そして開発者が機能の背景を理解していることで「ユーザーがこのニーズを満たしたいのであればxxの機能があったほうが良いのでは？」等の新たな提案も生まれやすくなりました。
振る舞い駆動開発の副次的な恩恵として開発者がやらされ仕事で実装するのではなく、視座を高くもって開発に取り組むことが実現できたことも良い点でした。
終わりに
いかがでしたでしょうか。
私の所属する事業部は発足してまだまだ成長段階でプロダクトの状況も0-1フェーズにあります。なのでこういったどういう構成で開発を進めるべきかなどを検討・決定していける機会が多いです。この記事をご覧になり、この事業部を一緒に盛り上げてみたいなと思う方が1人でも増えれば嬉しく思います！（詳しくはこちら ）
