
196
11
章 インフラストラクチャの変更のテスト
分析(https://codeascraft.com/2012/05/22/blameless-postmortems/)を実施することを検討しよう。
そして、対策のひとつとして、かならずテストを追加、変更することはもとより、テストを削除するこ
とを検討すべきだ。
次のような兆候が現れたときには、テストを大きく変えることを検討した方がよい。
●
テストが問題をキャッチしてくれることによって節約できる時間よりも、テストを修正、メンテナ
ンスするためにかけている時間の方が長い。
●
本番環境で問題が起きることが多い。
●
リリース時などのプロセスの終わりの段階で問題を見つけることが多い。
●
高水準テストのデバッグ、トレーシングのために時間を使い過ぎている。
インフラストラクチャのユニットテストのコードカバレッジ
インフラストラクチャのユニットテストにコードカバレッジ の目標を設 定したくなってもそれ だ
けは避けなければならない。構成定義は非常に単純なものなので、インフラストラクチャのコー
ドベースは、ソフトウェアのコードベースと比べてユニットテストが少なくなることが多い。ユ
ニットテストのカバレッジに目標を設定すると(ソフトウェア開発の世界では、目標設定は激し
く批判されているが)、チームは否応なく役に立たないテストコードを書いてメンテナンスする
ことになる。しかし、無駄なテストがあると、よい自動テストを維持するのがずっと難しくなる。
11.3
バランス