単体テストTips

久しぶりに新規開発をして、ガッツリ単体テスト仕様書を書くことになった。

レビュー指摘を踏まえて、ここに要点をまとめる。

１、マトリックスで考える

⇒基本的に、T/Fで考える。詳細設計書を忠実に書き起こしただけで満足しない。

設計書には、ifの場合の話しか書いていなかったとしても、ケース上は、if文を通らないパターンも表現されないといけない。

if文があれば、if文に入る/入らないの2ケースが必要。Aのケースがあれば、Bのケースを考える。C,D,E…どこまで考えれば良いのか整理する。テスト条件が複数必要な場合は、その条件数分、マトリックス化して、ケースに落とし込む。テスト実施不可のケースがあったとしても、マトリックス上表現はしておいて、グレーアウトすると網羅性を担保できる（※）。

※この点について、前に別案件でクライアントレビューで指摘を受けたことがあった。テストケースレビューする前から、鼻からグレーアウトするくらいだったら、そもそもケース切らないで良いんじゃないの？と言われたことがあった。しかし、網羅性を担保できなくなる、と言って、食い下がったことがあった。お客さんによっては、不要と言う人もいるようだが、そこはこちら側の考えを通して良いと思った。

２、曖昧な表現は避ける

⇒テスト実施者が迷う表現は避ける。詳細設計書がちゃんと書けてれば倣うだけでいいが、そうじゃない場合は、翻訳が不要なレベルに落とし込んだ表現を使用する。文脈を捉えていないと理解できない表現はダメ。

〇ハマったところ

for文についての記述で「〇〇へ戻る。」と、詳細設計書に記載があって、そのケースを書き起こす際に、該当のデータの次のデータがfor文に入ってくるログを確認することを期待結果とした。その際の表現として、「次のレコードを確認する」としてしまったが、「次のレコード」って、曖昧さが残ってしまっている。。ここは、SVに確認後、内容を更新する。「〇〇が△△になる」って表現だったら、〇〇を確認すれば、それで良いけど、「〇〇へ戻る」という表現等の場合、その記述自体に中身が無いから、確認のしようが無い。だから、その次に起こる事象を持って確認する、というのは正しいのか？要確認。