BDD は Given, When, Then のことだと勘違いされているんじゃないか
たまたま社内で自分が主催しているアジャイルに関する勉強会で BDD (Behaviour-Driven Development) の話をすることがあった。
個人的には、「Given, When, Then でテスト書くやつでしょ？」といった形で Gherkin記法 だけが一人歩きしている印象があるためその誤解を解くことを目的にその勉強会では話題に挙げたのでその熱が冷めないうちに自分の認識のメモを残しておきたい。
とはいえ、 https://cucumber.io/docs/bdd/ を読めば全てが書いてあるので気になった人はそちらを参照して欲しい。
前置きはそれくらいにしつつ、上記のドキュメントの中から抜粋してきた以下の画像が BDD の全体を示している。
この図が言わんとすることは、 BDD というのは Discover Formulation Automation の3つのステップで構成されているということである。
またそれぞれのステップでは以下のようなことをすることが想定されている。
Discover: Example Mapping (実例マッピング) をはじめとした手法により、職能を越えてチーム全体で要求をより深く理解するFormulation: Gherkin記法 (に限らない) を用いてDiscoverで理解した要求に関するルールを構造的なシナリオに起こすAutomation:Formulationで構造化したものを生きたドキュメントとするために Cucumber などのフレームワークやツールを利用して自動テストとして定常的に実行しその仕様が正しいことを保証し続けるようにする
これを踏まえると「Given, When, Then でテスト書くやつでしょ？」というのは実は真ん中の Formulation にしか着目していないことになる。
よく「Given, When, Then でテスト書くやつでしょ？」のあとに 「で何が嬉しいの？」と続ける人を見かけるが、そのメリットに気づくのが難しいのは当然で、なぜならば BDD がやりたいことの真ん中だけを抜き出してしまっているからである。
BDD の目的を雑に書いてしまうと 「職種を越えたチーム全体で要求のことを深く理解し、それを生きたドキュメントとして残すことで開発中や将来にわたって仕様を開発者以外も含めて正確に理解することを支援したい」 ということであって、途中の Formulation やそこに出てくる Gherkin記法 はあくまでもこの目的を達成するための How でしかない。
以上のことより、BDD を聞いた時に反射的に「Given, When, Then でテスト書くやつでしょ？」となってしまう状態は誤解であり BDD はテストの書き方や構造化の仕方ではなく、より抽象的な課題を解決しようとした試みなのだと捉えている。
冒頭でも紹介した通り、 https://cucumber.io/docs/bdd/ を読めば全てが書いてあるので気になった人はそちらを参照して欲しい。
また自分の観測上だと The BDD Books - Discovery (自分の感想ページ) という本が日本語の文献だと最も BDD のことを詳細に説明していると感じているのでぜひこの本も手に取ってほしい。
余談
個人的には、BDD 自体の勘違いを解消したいとは思っているのだが、とはいえ Cucumber を用いて書くテストが癖が強いものになってしまうのもまた事実だと感じている。
例えば、ユニットテストに代表されるようなクラスに閉じたテストなどとは相性が悪いと思うし Kotlin での例 などを見ても可読性が良いとは言いにくいと思う。
全てに言えることではあるが、 「ツールや考え方については背景も含めて正しい理解を持った上で適用するかどうかは場合によるし、バランスを考える必要がある」 という考えなのでこの記事は BDD の取り組みをおすすめするという趣旨の記事ではないことには注意してもらいたい。