#book #r2022  [https://leanpub.com/bddbooks-discovery-jp](https://leanpub.com/bddbooks-discovery-jp) # なぜこの本を読んだか 安定の [broccoli (nihonbuson)](https://twitter.com/nihonbuson) さんの本で積んでたのを読んだ。 このタイミングで積読から手に取ったのは、本業でテスト観点のレビューやテストについて考える機会があったためというのと夏休みが残り少なくなってしまいしゅっと読めるものを探してたから。 # 何が書かれている本か BDD の本というタイトルがついてはいるものの、想像するような Given/When/Then のシナリオ形式で自動テストを書くという話ではなく (そもそも本書の中でも以下のようにかなり下流の工程であることが触れられている) いわゆるテストのシフトレフトに代表されるようなプロジェクト全体にテスターが関わっていくという話が書かれていた。 > 多くの開発チームは、テスト自動化を改善したいという願望から BDD にやって来ます。テスト自動化の改善は、BDD のアプローチに従うことの重要なせいかの1つですが、それは下流の成果です。説明している順序 (発見、定式化、自動化の順) でプラクティスを採用しない限り、期待されるメリットは得られません。 とくに本書は3部作の1つであり、導入的な位置付けなので概念の説明や `発見` 、`定式化`、`自動化` の中でいうと `発見` 8割、 `定式化` 2割くらいの印象の本となっている。 英語版では、「定式化」の続編が出ていた [https://leanpub.com/bddbooks-formulation](https://leanpub.com/bddbooks-formulation) # メモ ## BDDとは何か これがこの本の全てのような一節 > BDD はアジャイルなアプローチであり、順番に取り組む必要のある 3 つのプラクティ スで構成されています。 最初のプラクティスは発見 (Discovery) です。 これは、明確な 具体例の使用による構造化された協調作業です。 これにより、従来のソフトウェアプロ ジェクトで躓いてきたあいまいさや誤解を明らかにできます。 > 2 番目のプラクティスは、定式化 (Formulation) です。 これは、発見のプラクティスで 作成した明確な具体例をビジネスチームのメンバーが読みやすいシナリオに変える創造的 なプロセスです。 その後に行うシナリオのレビューにより、ビジネスが求めているもの をチームが本当に理解しているという確信を得ます。 > 3 番目であり最後のプラクティスは自動化 (Automation) で、シナリオをテストに変えるコードを記述します。 自動化のメリットは下記のように多岐にわたります。 本書の中では、[Example Mapping (実例マッピング)](https://speakerdeck.com/nihonbuson/example-mapping) を通した「発見」のプロセスについて詳細が書かれている。 こういった発見を開発中に見つかって計画の変更を強いられるような「偶発的な発見」と比較して「計画的な発見」 (おそらく意図的な発見とかそういう感じかなと行間を読んだ) と呼んでいる。 また、具体例 (Example) は以下の図のようにコンテキスト、アクション、結果の3つに分解できるという部分も普段からなんとなくこういう整理をしていた自分としては言語を獲得したように思うのでよかった。  ここでいうコンテキストは、アクションが実行される前のシステムの状態のことを指す。 (自分はこの整理をする度に State Monad っぽい感覚にいつもなる) 最後の方にさまざまなツール上で実例マッピングを付箋以外でどうやって絵として表現するかというのが紹介されていてよかった。特に自分は普段から PlantUML を利用したりするので以下のようなマインドマップ形式がよかったなと感じた。  # 感想 実例マッピングのコンセプトを紹介する本やブログ記事などのリソースは増えてきたもののそれこそ具体的なシチュエーションをベースにしてどうやっていくかが会話形式で割と詳細に書かれているのはよかった。 また、上にもあるように「コンテキスト」＋「アクション」-> 「結果」という構図を普段からなんとなく意識していたが今後はこの本で書かれていたというように引用していこうかなと思う。