テストコードを書いていることの悩みの1つにテストコードをどの粒度で書けばいいのか、ということがあります。
例えばバッチの場合、大きく分けると
- エントリーポイントのFeatureテスト
- Unitテスト(主にサブのモジュールの詳細なテスト)
のようなテストがあります。
前者はバッチの機能全体的なテスト、後者はサブのモジュールのテストとなります。
一般論としてはモジュール単位の詳細なケースわけに関してはUnitテストを使い、その結合としてFeatureテストを行いますので、数としては必然的にFeatureテスト > Unitテストとなります。
このような考え方を一般的にはテストピラミッドというようです。
難しいのは、以下のような観点です。
- サブモジュールの数が少ない(極端なケースだと1つ)と、FeatureとUnitの差がほとんどなくなってしまう。(エントリーポイントがただ呼び出すだけなど)
- Unitテストごとの全組み合わせをFeatureでやるということが不可能ではないので、Featureに関してどのケースをテストするかということはどうしても個人の判断が残る
- テストケースをうまく書けるかは元のコードがいかにモジュールごとに別れているかということが大事になる
テストコードの品質、粒度をうまくきりわけられるかというのは本体のコードに依存する部分が大きいため、そもそもの本体のコードの品質に依存する部分が大きいため、
- 適切にモジュールにわかれているか(モジュールごとにわかれていないとそもそもテストがかけない)
- 長い関数を書いていないか(関数が長ければ長いほどテストが難しくなる)
- 責務の分離がしっかり行えているか(責務が大きすぎる場合、そもそもUnitテストの粒度を細かくすることができない)
などといった点が重要になってくると思います。
参考文献
