OOP実装とは対照的に、手続き的実装をとった既存の実装済みコードのユニットテストを書くにはどうしたらいいですか？私たちはJava/Springを使用していますが、異なる懸念のためのさまざまなBeanはありません。それらはすべて主要な機能の1つにつき1つの大きなクラスに混在しています。 （EG：各バッチジョブのクラス/ Bean、DAO、いくつかのutil型Beanがあります）。非常に少ないユニットでテストコードをユニット化する方法
テストする必要があるこれらの主要なクラスは約1k〜2k行のコードであり、それらが使用する唯一の依存性注入/ OOPはDAOといくつかの奇妙なユーティリティです。彼らは、彼らが共有しているインターフェースのために実装する約1つのパブリックメソッドを持っています。
リファクタリングから始めます。現代のIDEは、コードセマンティクスを壊したり変更したりすることなく、安全にリファクタリングすることができます。しかし、あなたは意識的にこれを行い、賢明でなければなりません。
他のクラスの依存関係ではない「外部」クラスから開始します。
最初の手順はできるだけ多くのメソッドを抽出することです。通常、コードのブロックを区切る空白行/コメントがたくさんある巨大なメソッドを見つけると、それらは抽出のための良い候補です。ループ、ネストされた条件文、long switchなども考慮する必要があります。
という名前のあまり有名なものがありましたら、という名前のメソッドを見て、それらを上下に動かしてグループ化してみてください。あるメソッドが密接に結合され、論理的に依存している場合は、それらを別のクラスに抽出します。 IDEがお手伝いします。
このプロセスは、すべてのレイヤーおよび複数回繰り返すことができます。小さくまとまったクラスを目指しましょう。あなたが名前を付けることができない場合は（例えば、 "と"を使ってどのメソッド/クラスが表現されているかを表現する必要があります）、さらに抽出してください。
もちろん、それをそのままテストすることができます - 私は、可能なすべての実行パスが異なる入力パラメータのセットで到達できると思います。しかし、これはデバッグの悪夢となるでしょう。
thisのいくつかのリンクです。
それ以上にしたいのであれば、私は"Working effectively with legacy code"を読む必要があります。ただ、トマシュNurkiewicz（第2完全I）からの偉大な答えにいくつかの他の考慮事項を追加する
：
は時々（まあ、いつも本当に）、それは少なくとも一つのカプセル化「受け入れテストを書くために便利ですリファクタリングを開始する前に（既存のものがない場合）パスしたら、リファクタリングを開始し、各ステップで「重要」なものを壊さないようにすることができます。重要なリファクタリングタスクを開始する前に、そのようなハーネスを使ってあなたをうまく保つことが非常に便利です:)
リファクタリングは、技術的なタスクではありません：大きなクラスを小さなものに分割してコードを抽出するだけでなくメソッドに。あなたは、オブジェクトの観点から、あなたのコードが何をすべきかを考え、より良いデザインに移行したいと考えています。長期的にはあなたの人生を楽にします。
大雑把に言えば、私は80-100行のコードの上に（そして理想的には50よりも低い）クラスを持たないようにしています。もちろん例外がありますが、それが大きくなると、主クラスに注入されるコラボレーターオブジェクトへの懸念を別々にリファクタリングしようとします。コードを読みやすく、テストしやすくします。
これはすばらしい答えです。そのアプローチに従えば、あなたのコードはすぐに堅牢になり、プロセスで確実なOOスキルを習得できます。 – Guillaume