kazokmr's Blog

試したこと、読んだこと、見たこと、聴いたことを書きたくなったら書くブログ

BDD in Action 2nd Edition の 第1章を読んだ感想

BDD

これは、BDD in Action Second Edition の 第1章 "Building software that makes a difference" までを読み終えた感想文です。 www.manning.com

第1章は最初の導入部分として、BDDが生まれた背景、概要、原則について書かれています。*1 BDDというと専用フレームワークを使ったプラクティスの話が多く、この本も読み進めてするとCucumberを使った実践例が出てきますが、この1章では「なぜこのようなプラクティスを使うのか」と言ったBDDの概念や背景が中心になっているので、BDDのことをより深く知るための基礎が理解できたと思います。*2

この中で特に印象に残ったことをいくつか取り上げてみます。

BDDの原則

1.3.3 の BDD principle and practices は、1章の中でも特にボリュームがあり、内容的にもここで書かれていることがこの章で最も説明したいことだったのかなと思います。

BDDの活動の流れと成果の具体例は以下のようになります。

ビジネスのゴール -> Feature -> Examples -> Executable specification -> Low-level specifications -> Application code

  • Featureは、ビジネスのゴールを達成するための機能であり、ユーザーストーリーなどで説明します。

  • Examplesは、機能の使い方に関する具体的な例で、Gherkin形式(Given ... When ... Then...)で書かれたシナリオになります。

  • Executable specificationは、受け入れテストでシナリオに従って機能が正しく動作することを検証可能にしたもので、いわゆるテストコードになります。

  • Low-level specificationは、シナリオを元に必要なコンポーネントの仕様で、ユニットテストのテスト仕様書やテストコードを指します。

  • Application codeは、機能として動作するコードで、例えばテストコードを使ってTDDなどで開発したプロダクションコードを指します。

これらの活動や成果に対するプラクティスやルールを、本の中で述べています。特に参考になった内容の幾つかを意訳すると以下のようになります。

  • ビジネスを理解する学習曲線は、初期に大部分のことを理解できるような対数的ではならないし、ましてや線形的に伸びるものでもない。時間と共に伸びたり停滞したりを繰り返しながら成長するので、要件の定義はプロジェクトの終盤まで繰り返し少しずつ行う。

  • ビジネスユーザー側の代弁者としてユーザーアナリストが要件を聞いて、開発者やテスターに伝えるのではなく、3者がプロジェクトの初期段階から協力しあい、ステークホルダーやエンドユーザーも一緒に話し合って、ビジネスのゴールやFeature、Examplesを作っていく。

  • ビジネス側は作って欲しい機能について、問題解決方法だけを提示して開発チームに作らせがちだが、開発チームと必要なことについて話し合うことや、開発チームの専門的な設計知識の恩恵を受けられるようにする。

  • テスターはExamplesを考えるときに、コーナーケース や エッジケースを思いつき、ユーザーに質問することができ、有益な例を追加することができるので、プロジェクトの初期から参加することは非常に価値があることである。

  • 自動化したテストを書くのではなく、"実行可能な仕様書" を書くようにする。同様にBDDにおけるユニットテストは、ただ単にクラスファイルやメソッド、ファンクションをテストするということではなく、コードの目的やコードをどのように使うかの例に従って動作することを検証する。

これらのプラクティスは、以前から様々な所で聞いたことがありましたが、BDDにおけるプラクティスの目的をベースにより深く理解することができました。

BDD以外の技術やプラクティスとの関連性

読んでいて「ここはあの技術のことだな」ってわかることや、実際に本の中で言及しているモノあり、BDDの概念と目的の元、多くのプラクティスを取り入れていると思いました。

BDDはTDDの実践例として考案されたのが始まりで今では別のプラクティスとして捉えられている。とはいえBDDがTDDに置き換わるプラクティスということではなく、TDDはコードの品質にフォーカスし、BDDはプロダクトの品質にフォーカスしているので両方を使い分けることが重要です。

また、ビジネスで使われる用語や語彙を使ってExamplesを作るプラクティスなどは、同時期に考案されたDDDのユビキタス言語と共通する物がありました。

そのほかにもビジネスアナリスト、開発者、テスターの三者が協力して、ビジネス側のステークホルダーやエンドユーザーと一緒にFeatureやExamples を作るのは、ユーザーストーリーマッピングのスリーアミーゴスの考え方と一致します。

もちろん、これらの根底にはアジャイルやイテレーティブな開発手法が関わっています。

2nd edition では、DevOpsやScaled AgileにおけるBDDの実践方法についても書かれる予定になっています。

次の第2章では、要件分析から自動化されたユニットテスト、受け入れテスト、機能的なテストカバレッジレポートと言ったプロジェクトの全体的な活動を通して、BDDのより実践的な例を説明するようなので、また読み終えた後にナレッジの整理のためにまとめたいと思います。*3

*1:この Second Editionは、MEAP という執筆中の内容が読めるプログラムであり完成版では無いのですが、1章は初版から図は差し替えられていますが、文章はほとんど同じでした。

*2:私自身はBDDを業務で実践したことはなく、概要を聞きかじったり、CucumberのHPのチュートリアルに触れたことがある程度です。

*3:ちなみに自分の裏のテーマとして英語の技術書を（ツールを利用しつつも）自分で翻訳しながら読み進めているので、読むペースがかなり遅いです。この1章も外出自粛のGW期間中だったからまとまって読みことができました。これを仕事の中でも進められるといいのですが、今のところはそういう訳には行かないので２章を読み終えるのにも1ヶ月以上かかりそうです。幸いにも(?)この本自体も現時点でまだ4章までしか公開されていませんが。