メインコンテンツまでスキップ

ベストプラクティス

プライベートな関数をテストする方法​

他のファイルから呼び出すことのできないプライベートな関数(つまりc言語でいうとstatic関数)は一切テストする必要はありません。プライベートな関数をテストのためだけにパブリックに変更したり、何らかの小細工をしてテストコードから呼び出せるようにするのはアンチパターンです。

プライベートな関数はパブリックな関数の中で呼び出されます。そのためパブリックな関数に対してテストを書けばプライベートな関数も自ずと検証されることになります。もしプライベートな関数を直接呼び出してテストしたいと思うなら、外部から振る舞いが見えにくい構成になっている可能性が高いので構成を見直しましょう。もしくはふるまいや仕様ではなく実装の詳細をテストしようとしているのかもしれません。実装の詳細を検証するテストは壊れやすく、テストコードのメンテナンス性低下につながるので避けましょう。

TDDは必須?​

必ずしもTDDで進める必要はないと思いますが、実装→テストコードよりもテストコード→実装の順のほうがテスト可能なインターフェースを保ちやすいと思います。

テストカバレッジ​

カバレッジ100%を目指す必要はありません。カバレッジはプロダクトコードの内、テストで通過した行数を計算しただけのメトリクスです。

例えば、以下のテストコードは条件分岐の片方しか検証していません。

テストコード
TEST(getAbsSuite, 絶対値を計算できる) {
    int x = 3;
    int y = -2;
    EXPECT_EQ(5, getAbs(x, y));
}
プロダクトコード
int getAbs(int x, int y) {
    if (x >= y) {
      return (x - y);
    } else {
      return (y - x); // こちらの分岐が検証されていない
    }
}

プロダクトコードのif文を3項演算子に変えただけでカバレッジが上がります。しかし、検証している内容はif文の時と同じです。

プロダクトコード
int getAbs(int x, int y) {
    return (x - y) >= 0 ? (x - y) : (y-x);
}

期待値チェックもれ​

チームで品質の基準をカバレッジ80%などと定めてしまうとカバレッジを上げるために期待値チェックをしない人が出てくるかもしれません。

以下のテストコードでは期待値チェック(EXPECT_EQによる結果の確認)が含まれていませが、これでもプロダクトコードを通過しているのでカバレッジに含まれます。

テストコード
TEST(getAbsSuite, 絶対値を計算できる) {
    getAbs(3, -2);
    getAbs(1, 5);
}