BDD in Action 2nd Edition 第6章を読んだ
BDD in Action 2nd Edition の第6章は、正しい要件を定義することの最終章として、前章で探索した主要な例を使って、フィーチャーのシナリオをGherkinフォーマットで書く方法を説明しています。
前半は、Gherkinの主要なキーワードの用途や使い方の説明で、これはCucumberのチュートリアルなどでも学べる内容でした。
この中で知らなかったキーワードにはBackground があり、複数のScenarioの冗長性を排除することができます。
これは書籍に載っていたことではありませんが、キーワードにRuleとExampleが追加されていました。
Rule は Featureの中で、Scenarioをグループ化できます。ExampleはScnarioの別名なので、用途はScenarioと変わりません。
RuleとExampleは、より実例マッピングに近い形式で表現できます。
章の後半では、優れたGherkinの書き方を紹介しています。
Gherkin を書く際に気を付けることとして以下のようなことが挙げられていました。どれもプログラミングの原則でよく言われていることと似ています。
シナリオでは宣言を書き、命令的な指示は書かない。(Howではなく、Whatを書く)
操作することや入力する内容などを1つ1つ詳細に書くのではなく、シナリオで達成したい目的に対して何をしなければいけないかに着目して書くとよい。1つの関心事に着目してシナリオを書く。 特に初めはシンプルな関心事から初めて、徐々に複雑なシナリオを組み立てる。
シナリオの登場人物に個性を付ける（ペルソナを作る） ユーザーや管理者のような味気ない役割だけではなく、目標・能力・背景などを付けると良い。また初めからペルソナを詳細に書くことに時間を費やさずにシナリオを書きながら付け足すと良い。
シナリオには必要なことだけを書く。容易に想定できることは省略する。
とあるフィーチャーのシナリオを書く時に、そのフィーチャー（画面）にたどり着くまでの汎用的で容易に想像がつく手順まで記述しない。特にGivenについてはシナリオを検証するために必要な前提条件だけを書く。既存のテストスクリプトやテストコードの手順をそのままシナリオとして書かない。
これらは指示・命令的なステップが多いから。「比較する」や「確認する」が含まれているシナリオは大抵、テストスクリプトのような書き方になりがち。各シナリオは独立して実行できるようにする シナリオごとに必要な前提条件を宣言して独立して実行できるようにする。一連のシナリオの纏まりを順番に実行する必要がある構造にはしない。（あるシナリオが失敗したら、後続のシナリオが実行できないことが無いようにする。）
個人的には経験上、指示的な書き方になりがちなので、この辺を気をつけていきたい。
ここまでの章で、シナリオをまとめたFeatureファイルを成果物とした、要件定義の進め方を学んできました。これまで自分が行って来たやり方とは全然違っているので慣れるまでに時間がかかりそうだが、作るべきことにより着目して明確に分かりやすい書き方で整理できそうに思えました。
