ユニットテストジェネレーターは、レガシーコードの操作に役立ちましたか？

テストカバレッジが非常に低い小さな（生成されたものを含めて〜70kLOC）C＃（.NET 4.0、一部のSilverlight）コードベースを探しています。コード自体は、ユーザー受け入れテストに合格したという点で機能しますが、脆弱で、一部の領域では十分に分解されていません。通常の容疑者（NMock、NUnit、Silverlightビット用のStatLight）を使用して、レガシーコードの周りに強力な単体テストカバレッジを追加したいと思います。

私の通常のアプローチは、コードの状態に満足するまで、プロジェクト、ユニットテスト、リファクタリングを開始することです。私はこれを何度も行ったことがありますが、うまくいきました。

ただし、今回は、テストジェネレーター（特にPex）を使用してテストフレームワークを作成し、手動で具体化することを考えています。

私の質問は、レガシーコードベースでの作業を開始するときに過去にユニットテストジェネレーターを使用したことがありますか？

私の恐れは、生成されたテストがコードベースの意味のニュアンスを見逃し、コードで意図された動作を明確に表現するテストではなく、カバレッジメトリックのためにテストを行うという恐ろしい状況につながることです。

少し違う見方をすることをお勧めします。問題なく既存のアプリケーションに新しい単体テストコードを追加しても、最良の結果が得られない場合があります。コードベースに慣れるためにこれを行っている場合、または本当に時間をかけてテストジェネレータをテストしたい場合は、私のコメントを無視してください。

実用的にするには、すべてのバグリストを確認する必要があります。次に、各バグの単体テストを作成し、その動作を確認します。理想的には、バグに到達したときに、バグごとに新しいコードを追加するだけです。

単体テストコードを追加する時期：

• 新しい機能を追加する
• リファクタリングされたコード
• バグを修正
• コードが何をするかを学ぶ
• バグが存在することを証明する

事後に単体テストを追加することの価値を定量化することは困難です。

私は通常、自分が質問者が望んでいることに反する答えを書くことを許可しませんが、これは伝えたい良い教訓だと感じています。