はい、私はこれがかなり典型的だと思います。従来のコードベースにテストコードを導入し始めたとき、私は自分自身が小さなユーティリティクラスとpojosを作成してテストしていました。元のクラスは、これらの小さなクラスを呼び出すためのラッパーになります。
たとえば、計算を行い、オブジェクトを更新してからデータベースに保存するメソッドがあるとします。
public void calculateAndUpdate(Thing t) {
calculate(t);//quite a complex calculation with mutliple results & updates t
dao.save(t);
}
calculateメソッドによって返される計算オブジェクトを作成することができます。このメソッドは、Thingオブジェクトを更新して保存します。
public void calculateAndUpdate(Thing t) {
Calculation calculation = new Calculator().calculate(t);//does not update t at all
update(t, calculation);//updates t with the result of calculation
dao.save(t);//saves t to the database
}
So I've introduced two new objects, a Calculator & Calculation.
This allows me to test the result of the calculation without having
to have a database available. I can also unit test the update
method as well. It's also more functional, which I like :-)
私が元の方法でテストを続けるなら、私は単体テストの計算をしなければならず、一つのアイテムとして保存しなければならないでしょう。どちらがいいか分からない。
私にとっては、2番目の方がコードデザインが優れていて、懸念がより分かりやすく、クラスが小さく、テストが簡単です。しかし、少人数のクラスが増えます。しかし全体的な複雑さは低下します。