BDD in Action Second Edition の第2章の感想
第2章を読み終えました。この章から構成が初版と変わってきているなと感じました。*1
この章ではプロジェクトのライフサイクル全体におけるBDDの使い方を理解する目的で、架空のプロジェクトを舞台にして話が進んでいきました。
また後半は実際にCucumberを使って、featureとグルーコード(Definition step)を起点に、テストしながらプロダクションコードを書き進めます。
実践部分は、掲載されているコードが間違っていたり(古い？)、所々説明が端折られていたので、実際に全部のテストを通すためには自分で考えながら進める必要がありました。 *2
英語を訳しながら進めたことや前述の様なこともあってか、BDDスタイルの書き方を やらされた感が強くあったり、スッキリしないところもあったので、これはまた自分なりにやり直してみたいと思います。
その他、この章で感じたこと
Cucumberの使い方ではなく、BDDの考え方を学ぶストーリーだったのが良かった。（とはいえ、DefinitionStepクラスのテストを通すためにはCucumberの初歩の使い方は知らないと詰まりそうですが。）
DefinitionStepを起点にコードを実装し始めるときは、Then -> When -> Given の順番に実装していくと良い。GivenとWhenは、前提と入力の位置付けなので、そこはリテラルな値やモック的なメソッドを仮実装したものを利用して、まずはThenを実証できる様にして置いた方が、組み立てやすいからと理解しました。
コードを実装していく所は基本的にTDDで進めるのですが、実装クラスに対応した「実装クラス名 + Test」の様なクラスを用意するのではなくストーリーレベルでテストクラスを作ったり、テストメソッドの中でWhenやThenの考え方を取り入れるなどBDDスタイルなテストコードの書き方も取り入れて、使い分けるのも良いと思う。
真の要件を見つける時に利用していた、インパクトマッピングも初めて知りましたが、Why->Who/Whose->How->What の流れで分解するやり方は問題の解決策を考えやすい方法だと感じましたし、本文を見ていて自分がWhatだと思っていたことはHowの段階であり、さらに分解して具体的にする必要があるんだと気付けました。
シナリオの記法は目的に応じて使い分けると良い。例えば、「ビジネスの目的のためにユーザーにさせたいシナリオなら、"Given ... When ... Then"」「ユーザーの目的のために達成したいシナリオなら、"As a … I want … so … that"」 と言った感じに分けて使うと良い。
開発チームやテスターといったプロジェクト側のチームが「本当の要件を発見すること」を強調していて、顧客側から「こう言う問題をこう解決したい」の様に、要件だけでなく解決方法も指示されたことも多かったので、まずはそもそも問題の本質を自分達も一緒になって改めて考えることを気をつけないと再認識しました。
実体験で、本章の様な顧客との会話のやりとりは要件定義ミーティングでも頻繁にあったのですが、この様なミーティングは、毎週または隔週の数時間だけと限られていたので、正しい要件を見つけるには時間が全然足らなかった。さらには、実装する機能のボリュームはやたらと多かったので、こんな進め方だとそりゃ上手くいかないよな。と再認識した。
この辺の要件定義の進め方や正しい要件の見つけ方は、BDDの学習を通して、身に付けていきたいです。
