多くのコード カバレッジが欠けているソリューションがあります。単体テストの作成を開始するには、このコードをリファクタリングして分離する必要があります。最善の戦略は何ですか？私はまず、ビジネス オブジェクトからのデータ アクセスからビジネス ロジックを分離して、まず何らかの組織を取得し、そこからドリルダウンすることを推し進める必要があると考えています。クラスの多くは単一の責任原則をサポートしていないため、それらのテストを開始するのは困難です。
レガシ ソリューションを採用し、それを形にしてコード カバレッジと単体テストに備えるための他の提案やベスト プラクティスはありますか?
レガシー コードを効果的に使用する を確認してください。
レガシー コードで行うべき最も重要なことの 1 つは、欠陥です。これは、単体テストを導入するすべてのコード ベースで引き続き行うプロセスです。欠陥が報告されるたびに、欠陥を明らかにする単体テストを作成します。定期的に壊れていたコード (つまり、「ああ、やった。 xyzzy クラスの plugh() メソッドがまた壊れた!) が壊れる頻度が減り始めていることがすぐにわかります。
本当に、やり始めてください。レガシー アプリケーションを一晩でカバーすることはできません。破損しやすいコードをヒットすることから始めて、分岐を開始します。コード内の新しい開発も、コード カバレッジが高いことを確認してください。
TDD のモットーは「レッド/グリーン/リファクタリング」であることを思い出してください。TDD に伴う退屈なタスクのいくつかを実行するのに役立つリファクタリング ツールを検討することをお勧めします。JetBrain のReSharperは人気があり、私の個人的な選択です。
十分なカバレッジが得られるまで、最初に既存のコードのテストを作成することをお勧めします。リファクタリングしたときに何も壊れないように、コードをそのままテストする必要があります。もちろん、モジュールのテストを作成し、次のモジュールに進む前にリファクタリングして、この作業を少しずつ行う必要があります。十分なカバレッジが得られたら、コードをよりテストしやすくするためだけにリファクタリングを続ける価値があるかどうかを判断できます。あなたの説明から、私はそうなると思います。
テストを作成することから始めます。テストをサポートするために、必要に応じてコードをリファクタリングします。
TDDについて読み始めてみてください。
リファクタリングしたときに何も壊れないように、コードをそのままテストする必要があります。
これらは、単体テストに役立つと思われる一般的なガイドラインです。
1) 境界オブジェクト (Win/WebForms、CustomControls など) を識別します。
2) コントロール オブジェクト (ビジネス層オブジェクト) を特定する
3) 境界オブジェクトによって呼び出されるコントロール オブジェクト public メソッドに対してのみユニット テストを記述します。こうすることで、アプリの主要な機能面をカバーしていることを確認できます。
あなたの場合、ビジネス ルールが境界オブジェクトと密接に結合されている場合、問題が発生します。私の意見では、アプリの機能要件に基づいて、ホット スポットに焦点を当ててリファクタリングを試みる必要があります。
これの実現可能性は、明らかに特定のケースに大きく依存します。