私は現在、他の 1 人の生協の学生と一緒に、完成間近のプロジェクトに取り組んでいる生協の学期にいます。このプロジェクトは生協から生協へと受け継がれてきたため、途中で悪い慣行が取られ、最後までテストが行われました。テスト中に何か新しいことを学ぶために、単体テストを書きたいと思いました。
ただし、現在の形式では単体テストが不可能と思われる 3 層の密結合アプリに取り組んでいます。一晩で認識できないほどコードをリファクタリングすることで、これらの概念の知識がない他の生協の学生を捨てたくはありません。では、コードをゆっくりと単体テスト可能にするには、どのような手順を踏む必要がありますか? 最初にファクトリ パターンを実装し、先に進む前に他の生徒にそれを理解してもらう必要がありますか?
私の知識に欠陥があり、何の問題もない場合はお詫び申し上げます。私はこれが初めてです:)
Michael Feathers によるレガシー コードの効果的な作業
ファクトリ パターンの実装が有効かどうかを判断するのは困難です。コードが何を行っているかによって異なります :)
Michael Feathers 著の Working Effectively with Legacy Code (サブスクリプションをお持ちの場合は Safari でも利用可能) は、タスクに最適なリソースです。著者は、レガシー コードを単体テストのないコードと定義し、コードをテスト対象にするための多くの保守的な手法 (セーフティ ネットなしで作業しているために必要) の実践的なウォークスルーを提供します。目次：
プロジェクトの途中で新しい開発手法を開始するのは非常に困難です。以前、最初から単体テストを行っていないプロジェクトに取り組んだとき、「新しいコードには単体テストが必要である」というルールを設定することをお勧めしますが、単体テストに圧力をかけないでください。古いコード用に書かれています。
もちろん、プロジェクトの構造がテスト容易性に適していない場合、これも困難です。
私の最善の推奨事項は、小さなステップでそれを行うことです.
テストを含まない単体テスト アセンブリ (またはプロジェクトなど) を作成することから始めます。次に、かなり明確に定義され、区切られた小さなコード領域を 1 つ見つけ、その領域の単体テストをいくつか記述します。ココーダーにも見てもらい、コードがチェックインされるたびに単体テストを実行するなど、いくつかの「ベストプラクティス」を開始してください（可能であれば自動的に）。
それが機能したら、ゆっくりと追加を開始できます。
ゆっくりがポイントです。そして、私が言ったように、最初から古いコードをテストから除外する方が簡単です。チームが単体テストの概念を理解し、それをより上手に記述できるようになったら、後でいつでもそれに戻ることができます。
コード内の主要な機能について、一連のブラック ボックス テストを作成するのはどうでしょうか。ASP.NET プロジェクトだとおっしゃっていたので、 WaitNやSeleniumなどのフレームワークを使用して Web ブラウザーを自動化できます。これにより、コードがどれだけ変更されても変わらない機能のベースライン セットが得られます。
プロジェクトの高レベルの機能をテストする十分な数のテストを取得したら、コードに飛び込み始めます。Simon P. Stevens が言及しているように、ゆっくりと作業します。Refactorの (無料!) コピーを手に入れましょう! Visual Basicの場合、Extract Method などの基本的なリファクタリングを自動的に実行できます。より大きなコードのチャンクをより小さく、よりテストしやすいチャンクに分割するだけで、機能を変更することなくテスト容易性を大幅に向上させることができます。