実務で学んだ単体テスト仕様書作成のコツ

はじめに

現在、単体テスト作成を進めている。

正直、納期を少し過ぎてしまった。

これまでにないようなボリュームのテーマだったからという言い訳はできる。

しかし、他のメンバーはボリュームが多い中でも納期内に仕上げているのを確認している。

メンバーというかリーダーの人だ。

だから、完全に自分の実力不足である。

本日、チームメンバーに単体テスト仕様書作成のコツを聞いた。

その内容を記事にしていきたい。

関数の単体テストは、メイン処理と分けて行う。

当たり前のことかもしれないがそれが意識できていなかった。

ボリュームが多いと頭の中がとっ散らかってしまう。

関数は、引数（入力）があって出力（返り値）があるというのが基本。

途中の処理はどうでもいい。

できるだけシンプルに単体テスト仕様書を作成していこう。

どんな入力と出力のパターンが考えられるか？

それだけを考えればいい。

一つのテストケースに複数の条件と期待結果を詰め込むこともできる。

しかし、それは難易度が高い。

まずは、一つのテストケースでは一つのことだけを確認しよう。

関数のシートを作成して、メイン処理からそこに「◯◯関数シート参照」という形で飛ばしてしまっていた。

それだと、関数が増えるにつれて分かりにくくなる。

そのため、メイン処理では、関数の戻り値が〇〇であるというようにしよう。

これは、ChatGPTに聞いたことだが、時間がない時は、チェック条件から考えるのではなく、期待結果から考えることをお勧めする。

そのほうが無駄がない。

期待結果が明確なら、テストケースのマトリクスもMECEに作成できるはずだ。

これを読んでいるあなた（自分が最大の読者）が、単体テスト仕様書作成というミッションを遂行できることを祈っている。

この壁を乗り越えれば、明るい未来が待っているだろう。

自分のために戦って欲しい。