回答。
レガシーコードのテスト自動化は、IT分野における最も古典的な問題の一つです。
問題の歴史: 多くの企業は、将来の自動化を考慮せずに書かれたシステムをテストする必要に直面しています。しばしば、このようなプロジェクトは文書が不十分で、高い技術的負債と隔離されたコンポーネントの不足を抱えています。
問題: 主な困難は以下から生じます。
- テストフックや統合ポイントの欠如
- テストのためのデータの隔離が不可能
- モジュール間の強い相互依存性
- コードに反映されていない異常や変更の多数
解決策: 通常、プロセスはステップバイステップで進みます:
- システム分析: 重要なビジネスプロセスを特定し、自動テストのカバレッジを正確に調整します。
- テストポイントの導入: 可能な限り、コードの一部をプロキシでラップしたり、テストダブルに適合させたり、依存性注入パターンを使用したりします。
- 自動テストの段階的カバレッジ: 最初は「最も簡単」で関連性の低いコードのテストを書きます。
- 継続的なサポートとリファクタリング: テストを追加した後、改善のためのリスクネットとして使用します。
主な特徴:
- テストは通常、ゼロからではなく、既存の機能の「ラッパー」から書き始めます。
- 階段的にテスト可能性をアーキテクチャに追加する必要があります。
- ビジネスは批判的シナリオの規制に最大限関与するべきです。
意地悪な質問。
レガシーコードの完全なリファクタリング前に自動テストを始めることは可能ですか？
はい、自動テストはリファクタリングを安全にするために必要です。「完全な完璧さ」を待つべきではありません。むしろ、テストは変化を恐れずに行う助けとなります。
すぐにレガシーコード全体を自動テストでカバーしようとするべきですか？
いいえ。最もリスクの高い利用頻度の高いシナリオに焦点を当てる必要があります。「すべてを一度にカバー」することは速度に悪影響を与え、意味がありません。
レガシーコードをテストするために、DIなどの現代のパターンを導入する必要がありますか？
いいえ、リソースが許す場合には使用が推奨されます。最初のステップは、少なくとも部分的な隔離、モック、コード内の特殊なテストポイントです。
一般的な誤りとアンチパターン
- 自動テストのために全てのコードを一度に移行する — プロジェクトは停止し、ビジネスの意義を失います。
- 重要でない機能の「偏執的」カバレッジ。
- 開発、テスト、ビジネス間のコミュニケーションの欠如。
実生活の例
ネガティブケース
チームはすべての古いアプリケーションをSOLIDパターンに書き直し、100%のコードカバレッジをテストしました。
長所:
- アーキテクチャの基本的な改善。
- 長期的にはテストが利益をもたらす可能性があります。
短所:
- 開発が数ヶ月遅れる。
- 常にバグが発生し、ビジネスの要件と同期しません。
- テストが書かれた時点でコードが陳腐化します。
ポジティブケース
特別なスタブを導入しながら、全体のコードを最小限変更し、重要な計算ポイントのための自動テストを導入しました。
長所:
- プロジェクトの遅延が最小限。
- 追加作業の際の信頼性が向上。
- 作業を進めるにつれてカバレッジを増やす可能性がある。
短所:
- 非標準的なアプローチを文書化するのが難しい。
- 一部のコードは依然としてカバレッジがないままとなります。