Rocky Mountain Ruby 2014で、Pivotal LabsのArjun Sharmaは、「用意したテストケースで、自信をもってデプロイできるのか？素早く不安なくリファクタリングができるか？」という条件を満たすには、コードのリスク程度に見合ったテストタイプを選択することを勧めています。

まずは、テストカバレッジ分析ツールについて、

• 良いカバー率というのは要注意。それをどう解釈するか。カバレッジの定義がツールごとに異なる可能性や、書き忘れたコードやアサーションはチェックできないことを考慮すると、単純に目標のカバー率を達成したからこのアプリは大丈夫ということにはならない。
• 一方で、悪いカバー率は、テストケースのどこに弱点があるかを明確にしてくれる役に立つ情報。

テストタイプを下記の三種類に分類して、それぞれのコストをまず認識する。

単体テスト

• 依存関係はスタブ / モックして、外部とのコミュニケーションはせずに、対象のコードユニットのみをテストする。
  • 実行が早い。
  • デバッグがすぐできる。
  • 機能のロジカルなサブセットをカバーできる。
  • 他のエンジニアにとってのドキュメントの役割を果たせる。
• 低コスト

結合テスト

• 外部の依存関係と実際にコミュニケーションしながら、対象のコードユニットをテストする。
  • 実行スピードが遅いことがある。
  • 単体テストよりはデバッグが難しい。
  • アプリの各パーツが期待通りにやりとりできるか確認できる。
  • 劣化テストができる。
• 中コスト

アクセプタンステスト（システムテスト）

• システム全体のテスト
  • 実行スピードが概ね遅い。
  • デバッグの難易度は高い。
  • ビジネス要件を満たしているかどうか確認できる。
  • 劣化テストの情報が最も手に入る。
• 高コスト

次に、コードのリスク度合いについて、

リスクが高いのは、

• 経済的損失もしくはデータ損失を引き起こす可能性のある箇所
• たくさんのトラフィックをさばくページに関係するコード
• 複雑なコード

コストとリスクのバランスについては、

• 高リスクのコードユニットは、必ずカバー。高コストのテストタイプを使う価値あり。
• 低リスクのコードユニットには、低コストのテストタイプを利用する。

最後に自分のプロジェクトについてチェックすべきポイントは、

• 高リスクなコードユニットはテストでカバーできているか？
• 低リスクの機能を高コストのテストでカバーしていないか？
• 高コストのテストを低コストのものに替えられるところはないか？

#テスト

ワザノバTop200アクセスランキング