この記事では、変更に強いテストケースの書き方について自分なりに考えてみようと思います。
きっかけはデザインパターン
きっかけとなったのはこの本です。めちゃくちゃ面白い上にわかりやすいので、とってもおすすめです。 booth.pm この本がとても面白くて、デザインパターンに興味を持ったのですが、そもそもデザインパターンはソースコードの保守性を高めるために作られたもの（多分）ということを知りました。 そして私は、それをソフトウェアテストにおいても活かせるのではないか？と考えました。 ※デザインパターンについては学習中なので、誤りを含む可能性があります。あらかじめご了承ください。詳しく知りたい方はQiitaのブログなどを参照ください。
活かせそうだと思ったデザインパターン
observer pattern
このパターンは、「オブジェクトが追加されたり削除されたときに、別のオブジェクトに何らかの通知をしたい場合」に威力を発揮します。 （本では、「地下アイドルのファンが増えていったらどうなるか」という説明をしていました） ここから、テストケースに置き換えると次のようなことが言えるなと思いました。
変更に弱いパターン
変更に弱いパターンは、「仕様書をコピーした画像や文言をテストケースに埋め込んでいる」パターンです。 これでは、仕様書が変更されるたびにテストケースを修正しなくてはいけません。
変更に強いパターン
頻繁に変更される仕様書をテストケースの参考資料として添付したい場合は、そのまま貼り付けずに、テスト実行時に仕様書を参照させるというのも手です。
※仕様書の置き場所が決まっている必要があります。
また、いわゆる低位レベルテストケースと高位レベルテストケースということで、具体的な値を仕様書から探してきて記載する（＝低位レベルテストケース）のも危険です。
※変更の頻度にもよります。
それよりは、その値をテストしたい意図だけわかるようにしておき、具体的な値はテスト時に決める形式（＝高位レベルテストケース）も選択肢としてアリでしょう。
mediator pattern
mediatorパターンは、オブジェクトが協調して動くとき、例えば「フォームAの入力内容に応じてフォームBの内容が決まる。フォームBの入力内容はCとDに影響する」というように依存関係が複雑になる場合に効果を発揮します。こちらも、本に載っている例がとても面白くわかりやすいので、ぜひ読んでみてください。
同じくテストケースに当てはめて考えてみます。
変更に弱いパターン
テストケース間にも依存関係が発生することがあります。「このチェックはテストケースAに準ずる」とか「テストケースBでテストしてたら、このテストは省略する」とか書くと依存関係が生まれます。これが多くなりすぎると、変更時のメンテが大変になります。
強いパターン
まず、極力他のテストケースを参照させるのをやめます。一つ一つのテストケースが独立して成り立つように作成します。
どうしても参照させたいときは、階層構造にするなどして、参照するテストケースを一つに限定します。テストケースAもBもCも、皆参照先は決まった参照先Zにするのです。
極力、「テストケースAはBを参照してて、CはDを参照してて〜」という作り方をやめることで、依存関係が整理され、Zと各々の関係のみを考えるだけで済みます。
いかがでしたでしょうか。 結構当たり前にやっていることも多いかもしれませんが、あまり考えずにテストケースを作ってしまうと、変更に弱いテストケースになってしまうこともあるのではと思います。
変更に強いテストケースの書き方も、頭の片隅に置いておくといいのではないでしょうか。
