テスト項目の作り方について。
単体テスト書のレビューをしていて、なるべく効率的に網羅的にできるテスト仕様書の作成について。
納品物としてではなく、開発の高速化と品質をあげるためのテスト仕様書を。
Contents
項目の分解方法
複雑なシステムの場合、テスト項目の切り分け方が大事になってきます。このブログではこのような項目を便宜的にテスト項目の縦項目と定義します。
自分なりに考えたコツなどを。(まだ完全にできるようにはなっていないですが・・・)
困難は分割せよ
全ての一度に切り分けるのは難しいので、Controllerでのスタート→エンドごとに小項目を作り、そのカテゴリーごとに分けます。
典型的な例としては、以下のようなものでしょう。
- Inパラメータのバリデーション
- 分割可能な単位の処理(綺麗に書かれているプログラムの場合、コントローラーから呼ばれる１つの単位がテストの小カテゴリ単位になるかと思います。)
- 比較的大まかなメソッド(シーケンスの１フロー)
- 比較的上位のif文やswitch文(処理が大きく分かれている部分など、)
- さらに下部の小さい単位へ・・・
上記の場合、リポジトリやサービスがこの単位になっているとPHPUnitなどのテストツールなどで機械的にテストできるので楽だなと・・
条件分岐の組み合わせ
単純に考えると、Inパラメータや条件分岐となっている箇所の分だけ条件分岐の数が増えてきます。
ただ現実的に考えるとかなり難しいので、メインとなる条件の分岐のみになるケースが多いかと思います。
Unitテストが理想ですが、そうでなければExcelなどを使ったり、楽に網羅的に組み合わせを作れるようにしましょう。
画面からPOSTする場合でも手入力だときついので、JSONなどを自動で作れるようになればパーフェクトかと思います。
エビデンス(結果の担保)
テストやってて憂鬱なものNo1だったんですが(時間がかかる上に仕事のための仕事という感じがして私が嫌いなもののトップ)、上手く使えば結果の担保ができますので、積極的な意味を見出していこうと思います。
スクショ
一般的にエビデンスといえばがこちらが一般的でしょう。
スクショ撮るとか、大嫌いな作業ですが(汗)、メリデメを整理して見ようと思います。
メリット
- スクショツールを使えばいいので、結果の保存が楽でスキルがいらない
- 画像で情報を伝えられるのでレイアウトなど文字情報で伝え切れない情報を伝えられる
- 画面系の結果に関して伝えられる情報量が多く、正確
デメリット
- エビデンスを保存するのが(特に数が多くなってくると)手間
- 入力値のコピペができない
- 検索などもできない
レイアウトを伝えるなどがなければ、デメリットの方が多いですかね・・・
SeleniumやJavaScriptでヘッドレスブラウザを使うというやり方を使えばスクショを自動的に作れることもありますが、
ログ
メリット
- プログラムのInとOutをセットにして情報を伝えることができる
- ログの収集方法などを工夫するができる
- Inパラメータをセットにするなど情報を綺麗な形に圧縮できる
- 文字情報なので検索ができる
デメリット
- テスターがエンジニアでないと、エビデンスを集めることが大変
- ログが綺麗に出ていないとそもそもこの手法が使えない
- ログ設計に依存する部分がある
レスポンス
ログに近いですが、APIなどの場合はこの方がスクショよりもわかりやすいでしょう。
メリット
- InとOutなどを定義することで結果としての仕様のコミニケーションの齟齬を防ぐことができる
- テストの再現性が高い
- JSONを入れておけば、仕様書になる
- ユニットテストのように効率化することができる
デメリット
- APIでないと使えないケースがある(通常の画面側の処理でそれを行うのは難しい)
事前データ
これがテスト仕様書にあるだけでテストの効率が数十倍になります。効率の良い開発を進める上での土台といっても良いでしょう。
仕様がわかる方を捕まえて、トラン系のデータと周辺のマスタ系のデータを一通り作っておきましょう。
データ作りのコツについて
- 何度も繰り返すことを前提にすると、常にdrop文、truncate文をセットにしておく(これがないと既存データのせいでテストできないことが多い)
- 外部キー制約はテスト時は外しておいた方がいい
- リレーションが複雑な場合は、まず組み合わせを考えてデータを横一列に並べて作成し(この場合はExcelが便利)、それをリレーションに分解する(あるいは自動化する)
