テストコードのレビューをする前に自分なりのテストケースを整理する

前提

ここでいうテストコードとはテストケースの管理とテストコードの管理を一緒くたにやっている、「実装しました！単体テストも書いてコミットしました！」みたいなテストコードのことです。スプレッドシートに整理してから誰かに承認されたテストケース一覧をもとに書かれたテストコード、みたいな場合は対象外です。

何の話か

一般的にコードのレビューは

• バグがないか
• 設計や命名が良い感じなのか

を軸に行われることが多いと思います。一方テストコードのレビューをする場合は上記に加えて

• テストケースのパターンが十分動作を担保しているのか

という観点が増えます。

このテストケースのパターンのレビューをする際にテストコードを見ながらパターンの確認をするのではなく、実装や仕様から自分なりのテストケースのパターンを整理してから実際のテストケースのパターンをレビューしたほうが良い、という個人的な経験則の話が本記事の趣旨です。

どうやるか

テスト対象の実装として以下のようなメソッドがあるとします。

/**
 * 料金を返す
 * @param age 年齢（0-7, 8-15, 16-59, 60-200）
 * @param type 会員タイプ（`silver` or `gold`）
 * @return 料金
 */
public int 料金(int age, String type) {
    // なんか実装
}

これに対して以下のようなレビュー対象のテストコードがあります。

@Test
void test_0歳Silver_100yen() {
    // テストコード
}

@Test
void test_0歳Gold_50yen() {
    // テストコード
}

@Test
void test_7歳Silver_200yen() {
    // テストコード
}

@Test
void test_7歳Gold_200yen() {
    // テストコード
}

...（続く）

これをレビューする時に、テストコードを上から見ていってテストパターンが十分かどうかを確認するのではなく、コードを見る前に以下のように自分なりのテストパターンを作るとレビューの精度が上がる気がする、みたいな話です。

年齢	会員タイプ
0	silver
0	gold
7	silver
7	gold
8	silver
8	gold
...	...

なんでそう思うか

上の例くらいであればメソッドの仕様からテストパターンを頭の中に展開して、その頭の中のテストパターンを実際のテストケースに当てはめていく、みたいなこともできなくはないと思います。

が、自分の頭の中のテストパターンと実際のテストコードを当てはめてく間に頭の中のパターンがぐちゃぐちゃになったり、テストコードが正しく動いているかはちゃんと見ているのにパターンが網羅的かどうかをそもそも見ていなかったり、パターンをレビューしているつもりでもテストコードに引っ張られて本来の自分なら思いついていたであろうテストケースを見落とす、みたいなことが私の場合頻繁に起きます。

ので、もういっそのことテストパターンの複雑さに限らず毎回先に自分なりのテストケース一覧を書いてからレビューしようかな、と思った次第です。
自分が見落としていたテストケースがテストコードに存在するのを見た時の「自分はそういうパターンが抜けがち」、という自分に対するフィードバックもこのやり方のが強くなる気がします。

時間かからない？

かかると思うので、テストの網羅性にそこまでこだわらないプロジェクトの場合は違うやり方をするかもしれません。