レガシープロジェクトをテストフレームワークにラップする
C＃で記述された古いプロジェクトをテストフレームワークでラップする作業をしています。
私が抱えている最大の問題は、他のクラスと非常に密接に結合されているクラスがたくさんあることです。これらのクラスはすべて、独自にデータベースを呼び出し、多くのクラスはメソッド内で他のクラスを直接インスタンス化します。
問題は適切に解決されたと思いますが、簡単な健全性チェックを行いたいと思います。すべてのオブジェクトのインスタンス化を抽象的なファクトリに移動することを考えていました。クラス内のデータベースと通信するアダプターを直接インスタンス化する代わりに、依存関係反転を使用して、ファクトリー内のインスタンス化時にアダプターをオブジェクトに渡します。
次に、データベースを直接呼び出すのではなく、モックアダプターをオブジェクトに渡すテストファクトリを作成できます。
オブジェクトが独自のメソッド内で他のオブジェクトをインスタンス化するときは、インスタンス化したのと同じタイプのファクトリを使用する必要があります。オブジェクトを作成したファクトリをコンストラクターに渡して、他のオブジェクトを作成したいときに、プロパティとして保存することを考えていました。それは良い考えでしょうか？
混乱して申し訳ありません。詳細が必要な場合はお知らせください。
基本的なパターンがあります。データベースやファイルシステムなどのアウトプロセスリソースと通信するクラスのインターフェイスを定義します。次に、「実際の」クラスにインターフェースを実装させます。引数としてそのインターフェイスのオブジェクトを受け取るコンストラクターを公開し、そのフィールドまたはプロパティの型を具象クラスではなくインターフェイスになるように再定義します。
オブジェクトをインスタンス化するコンストラクターは、オブジェクトをパラメーターとして受け取る他のコンストラクターにオブジェクトを渡すだけです。
ここで抽象ファクトリが必要かどうかはわかりません。機能する場合はそれを使用しますが、すでに複雑で密結合されたアプリケーションにさらに複雑なレイヤーを追加します。私は貧乏人のDI：コンストラクター引数から始めます。
全体像として、このリファクタリングの仕事は一連の外科的処置として行われるべきです。アプリケーションの小さなスライスを取り、この設計方法論を適用します。メスはあなたの親友です。一挙にできる限りリファクタリングしたくなるかもしれませんが、アプリケーションに影響しすぎます。少しだけ。これは象です。この食事を少し食べてください。アプリケーションの価値の高い領域を最初にターゲットにしてください。この領域では、最も多くの欠陥が発生するか、機能がエンドユーザーにとって最も重要です。
リファクタリングを開始する前に、アプリケーションの主要なユースケースに対応するエンドツーエンドのテストをいくつかまとめることを恐れないでください。そうすることで、これらの外科的切開をすべて行うときに、マクロの観点から期待どおりにそれらの症例が機能することを確認できます。