サニティチェック - JUNIT使用時のオブジェクト数の大幅な増加

私はプロジェクトで初めてJunitを使用しています。私はコードを再構成することに魅了されています。私が気づいたことの一つは、コードの断片をテストできるようにするために作成したオブジェクトの数が大幅に増えていることです。これは典型的ですか?

ありがとう、

エリオット

2
おそらく、これが起こった例を投稿することができますか?
追加された 著者 Raedwald,
テストクラスや、通常のコードで追加のクラスやオブジェクトについて話していますか?
追加された 著者 Mark Rotteveel,
"重要な"増加とは何ですか?私の経験では、 "payload"クラスごとに1つのJUnitクラス、つまりfoo.java < - > fooTest.javaを作成します。テストの方法の数はかなり多いかもしれませんが、それはあなたがいかに綿密なものになりたいかによって決まります。
追加された 著者 mazaneicha,

3 答え

はい、私はこれがかなり典型的だと思います。従来のコードベースにテストコードを導入し始めたとき、私は自分自身が小さなユーティリティクラスと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番目の方がコードデザインが優れていて、懸念がより分かりやすく、クラスが小さく、テストが簡単です。しかし、少人数のクラスが増えます。しかし全体的な複雑さは低下します。

1
追加された
それは静的である可能性があります、私は1つに3つの線を組み合わせることができますが、それは単なる例です。元のcalculate()メソッドは、複数の結果を持つことができる計算を行い、およびはThingオブジェクトを更新します。この点は、2つのメソッドを分離することです。結果が複数ある場合は、中間クラスが必要です。上記は一般的な技術の説明に過ぎない。
追加された 著者 Matthew Farwell,
なぜあなたの電卓は静的ではありませんか? .calculate(t)。なぜ計算をしなければならないのですか? Calculationオブジェクトにラップするのではなく、実際の計算結果をupdateメソッドに渡すだけですか?
追加された 著者 c_maker,

Yes, this is normal.

一般的に、あなたのクラスとメソッドは、より小さい/もっと集中しているので、理解しやすく、テストしやすくなります。これにより、より多くのファイルと実際のコード行が生成される可能性がありますが、コードをより洗練されたデザインにする抽象化を追加しているためです。

単独責任原則についてお読みください。 Bobさんはまた、クリーンコードと呼ばれる彼の著書に触れている例をいくつか再考しています正確にはこれらの点。

あなたが単体テストをしているときにもう1つ。 依存性注入は、来るときに頭痛を軽減する最も重要なことの一つですあなたのコードを構造化する。 (説明のために、DIは必ずしもクラスを増やす必要はありませんが、クラスを互いに切り離すのに役立ちます。

1
追加された

あなたがどのような種類のオブジェクトを参照しているかによって異なります。通常、EasyMockやMockitoのような模擬フレームワークを使うとうまくいくはずです。その場合は、テスト目的だけに必要な追加クラスの数はかなり少なくなければなりません。メインソースコード内の追加オブジェクトを参照している場合は、単体テストの方がコードをリファクタリングして読みやすく、再利用できるようにすることができます。

0
追加された