振る舞い駆動開発(BDD:Behavior-Driven Development)の概要と評価
テスト駆動開発(TDD)を調べているときに振る舞い駆動開発(BDD)という言葉も出てきていたため、どういったものか少し調べてみましたのでまとめます。
1. 概要
1-1. 振る舞い駆動開発(BDD)とは
振る舞い駆動開発(BDD:Behavior-Driven Development)は、ソフトウェア開発の手法の一つで、開発者、テスター、ビジネス関係者が協力して、ソフトウェアの振る舞いをシナリオベースで定義し、それを自動化されたテストに変換するアプローチです。2003年にDan Northによって提唱され、特にテスト駆動開発(TDD)の進化形として、開発者と非技術者のコミュニケーションを改善することを目的に設計されました。
1-2. TDDとの違い
TDDはユニットテストを先に作るという思想でBDDとはレイヤが異なります。TDDが製造・ユニットテストの下流工程の話になのに対して、BDDはもっと上流のユーザテストのようなビジネス寄りの話になります。
TDDだけでは技術者とビジネス側のコミュニケーションのギャップが問題となることもあり、TDDの改善案としてビジネスと開発の共通言語となるBDDが提唱されました。
これだけ聞くとよりアジャイル開発に向いたテスト思想のようにも思えます。
1-3. 受け入れ駆動開発(ATDD:Acceptance Test-Driven Development)とは
似たような思想に受け入れ駆動開発(ATDD:Acceptance Test-Driven Development)というものもあります。
こちらも要件定義・受入試験のレイヤで、先に受入れテストケースを作ってしまおうという考えになっております。
BDDが振る舞い・ビジネス価値やユーザ体験といったものに重点を置いているのに対し、ATDDは受入基準(要件を満たしているか)に焦点を置いているため焦点が異なるようです。
1-4. 参考情報
以下のスライドにBDDが分かりやすいくまとまっていました。
以下はNewsPicksのユーザベースがBDDを行った参考スライドです。実例として参考になります。
2. BDDの手段
BDDは思想やプロセスになりますが、実現のためのツール(Cucumber)も用意されています。
2-1. Cucumberとは
Cucumberは2008年にBDDを実現するためのオープンソースプロジェクトとしてスタートしました。
※Cucumberはキュウリの意味ですが、深い意味はなく親しみやすさと軽やかさを意図したネーミングとのこと。
Gherkinという自然言語を定義しており、Given-When-Thenという構造を使って、ソフトウェアの機能や期待される動作をシナリオ形式で表現します。(以下例)
Feature: ユーザーログイン機能
Scenario: 正しいIDとパスワードでログインできる
Given ユーザーがログインページにアクセスしている
When 正しいユーザーIDとパスワードを入力する
Then ユーザーはダッシュボードページにリダイレクトされる
このシナリオと、シナリオに紐づくテストコードをそれぞれ作ります。実行するとテストコードが実行され、シナリオがどこまで成功したかなどのレポートが出力されるという感じです。
2-2. SpecFlow(reqnroll)とは
たまにSpecFlowというものも出てきますが、こちらはCucumber for .Netとして誕生したもので、.Net用のCucumberとなります。
また、途中Forkして「reqnroll」に変わったようで、reqnrollに置き換わっていくと思います。
2-3. Cucumberのコミュニティは運営の危機?
Cucumberコミュニティは運営危機にあるとの情報も参考スライドにありましたが、あまり正確な情報はわかりません。他にそういった情報はないのとChatGPTでも調べてもらっても出てこなかったです。
3. 普通の開発に比べてどうか、実際に使えるのか?
BDDは聞こえはいいですが、実際の商用開発で使えるのかが良く分からなかったので少し考察してみます。
3-1. メリットもあるが生産性は下がりそう
振る舞いシナリオはユニット・結合・総合・受入のどの工程にもないものですので、単純にやることは純増すると思います。その分ビジネス・開発での認識齟齬がなくなるというメリットもありそうですが。
シナリオの定義やメンテナンスなどやることが多くなるし、工程の初期にシナリオを作るため開発前半の生産性は下がると思います。そのため、費用対効果から予算を取って開発する企業には導入のハードルはあるのかと思いました。
3-2. Cucumberの情報自体が多くないし、学習コストもかかる
Gherkin自体なじみはないだろうし情報も少なく、ツールだけでなくこの思想やプロセスを正しく浸透させるには結構学習コストがかかりそうです。
小規模にお試しでやる分には面白いと思いますが、ある程度規模が大ききくなると導入のハードルがやはり大きそう。
3-3. ATDD+Playwrightでの自動化ぐらいで十分では
Cucumberの導入やCICDへの組み込み・学習や情報の少なさを考慮すると今の段階では導入コストに対してメリットがそこまで大きくない気もします。
個人的にはATDDの思想でシステムが満たすべきシナリオを定義し、それをPlaywrightで自動化してCIに組み込みする方が再帰試験のコストが下がっていくので良いのではないかと思います。
BDDはより価値を高めるという+の要素にはなるものの、今のプロセスを効率化してくれるようなものではないかと思いました。