コードカバレッジ
テストにおいて、
- コードカバレッジ：ある機能のコードのどの行がどのテストにより実行されるか計測する指標。
この指標はあくまでもテストによって実装コードがどの程度実行されているかを確認しているにすぎず、「コードの有用性」を表す指標でないことに注意。
したがって、コードカバレッジをテスト品質の絶対的基準とすることは危険である。
コードカバレッジの問題・注意点
- テストによってコードの「実行」は確認できてもコードが何か「有用」なことをやっているかはわからない。
- カバレッジ計測は小テストに留めておくとよい。
- 既定のカバレッジを満たすことをゴールとすることは危険。
テストで確認すべきこと
本来テストで確認すべき項目は「テストスイートの品質」「テストされる挙動」である。
作成予定あるいは作成済みのテストについて、改めて以下の点を確認しよう
- 顧客が期待するものすべてが動作するか？
- 依存関係における破壊的変更を捕捉できるか？
- [Q.] どんな具体例があるかな？
- テストは安定していて、信頼できるか？
- [Q.] 安定・信頼とは？
大規模テストスイートの落とし穴
テストコードの複雑化
継続的な機能開発によってコードベースが発展してくると、当然既存コードの修正をすることもあるだろう。 この時、自動テストの書き方が悪いと、既存コードの変更が難しくなるといった問題に直面する。
例）ある機能コード5行の修正で、修正機能とは無関係なテストが何十個も失敗する、、等
この問題で頻出な原因はモックオブジェクトの誤った利用によるものが多い。モックオブジェクトの限界と テストの品質改善の具体的な話は別の記事にて書くことにする。
大きなテストスイートの処理重い問題
テストが重くなる主な要因は
特に同期待ち、、「（どこかしらの処理応答を）待ってからチェック」は非常に危険。 少なくともユニットテストのレベルではなるべく行わないようにしよう。
まとめ
以上より、テストの品質維持はエンジニアの機能開発の生産性に多大な影響を与える問題であることが分かったかと思う。
エンジニア(とチーム)は様々な理由により「テストの品質維持」のタスク優先度を下げてしまいがちであり、個々のエンジニアの自助努力だけにはたよらず、開発組織として以下のような取り組みがもとめられる。
- テストは本番コード同等に扱い、品質維持に努めるべき
- テストの管理を簡単にするための投資を怠らない
- テスト実装・メンテナンスに機能実装と同等のインセンティブをエンジニアに付与する
これらの、決して少なくない時間と労力を割いてまでテストの品質維持を実施し続けるために、開発組織における「テスト文化」の醸成が必要となる。
以後の投稿でテスト文化について言及する。
