web-dev-qa-db-ja.com

Javaゲッターとセッターを自動テストする単体テストフレームワークはありますか？

Java（および他のコミュニティ、きっと））には、簡単なゲッター/セッターメソッドをテストする必要があるかどうかというよく知られた議論があります。通常、これはコードカバレッジに関するものです。これはオープンな議論であり、ここで答えようとしないでください。

このようなメソッドを自動テストするためにJavaリフレクションを使用することについてのブログ投稿がいくつかあります。

フレームワーク（jUnitなど）はそのような機能を提供しますか？例えば「このテストTは、クラスCのすべてのゲッター/セッターを標準であると断言するため、自動テストする必要がある」という注釈。

それは付加価値を与えるように思え、それが構成可能であれば、「議論」はユーザーのオプションとして残されます。

javaunit-testingjunit
38
Michael Easter

nitils 静的メソッドassertRefEqualsを使用してこれを行います。

8
Kevin Wong

これを行うライブラリやクラスがすぐに利用できることは知りません。これは主に私がそのようなテストに強く反対する側にいるので気にしていないためかもしれません。だから、あなたがそこに尋ねたとしてもmustこの見解には少し正当化する必要があります：

自動テストのゲッターとセッターがコードの品質やカバレッジに利益をもたらすとは思えません：これらのメソッドは他のコードから使用されている（そしてそこでテストされている、たとえば100％カバーされている）か、まったく使用されていない（削除される可能性があります）。結局、ゲッターとセッターはテストから使用されますが、アプリケーションの他の場所では使用されないため、そのままにしておきます。

このようなテストは簡単に作成できるはずです。 Apache Commons BeanUtilsを使用しますが、それ以外の方法で適切なテストを行っている場合は、本当に必要なのでしょうか。

13
Olaf Kock

このexact問題を解決するために OpenPojo プロジェクトを作成しました。

プロジェクトでは、次のことを検証できます。

  • Pojoコーディング標準を適用する（つまり、すべてのフィールドがプライベートであるか、ネイティブ変数がないなど...）
  • Pojoの動作を強制する（つまり、セッターは設定のみを行い、変換は行わないなど）
  • Pojo IDを検証する（つまり、注釈ベースの等式とハッシュコード生成を使用する）

チュートリアルを参照

11
Osman Shoukry

ほとんどの場合、setterとgetterは、内部フィールドを設定および取得するだけで、さらに多くのことを行います。オブジェクトは、有効な値のみを保持するという内部ルールをチェックする必要があります。例えば

  • null値は可能ですか？
  • 空の文字列は可能ですか？
  • または負の値？
  • またはゼロ値？
  • またはリストの値は有効ですか？
  • または最大値はありますか？
  • またはBigDecimal値に最大精度がありますか？

ユニットテストでは、無効な値がある場合に動作が正しいかどうかを確認する必要があります。これは自動化できません。

セッターとゲッターにロジックがない場合は、アプリケーションの任意の場所で使用する必要があります。オブジェクトがより複雑なテストのパラメーターであるテストを記述します。次に、リストの異なる値を使用してテストできます。

ゲッターとセッターではなくビジネスロジックをテストします。結果は、ゲッターとセッターのカバレッジにもなります。パブリックライブラリしかない場合も、メソッドはビジネスロジックで何らかの結果になるはずです。ゲッターとセッターにコードカバレッジがない場合は、それを削除します。

6
Horcrux7

私はそのようなことをしました。単純なJavaオブジェクトを受け取り、すべてのゲッターメソッドとセッターメソッドをテストするクラス http://sourceforge.net/projects/getterandsetter/

ゲッターメソッドとセッターメソッドはできる限り避けた方がいいと思いますが、それらがあり、テストに2行かかる限り、それを行うのは良いことです。

5
Facundo Olano

コードカバレッジよりもOOデザインを優先し、それらを必要とするクラスにそれらのフィールドを移動できないかどうかを確認します。したがって、これらのゲッターとセッターを削除できるかどうかを確認しますgetterとsetterは breaking encapsulation です。

3
philant

openpojoを試しています

私はタイヤを蹴ったが、それは仕事をしているようだ。

  1. プロジェクト内のすべてのpojoを確認できます。
  2. Pojoのベストプラクティスを確認するようです

このチュートリアルでクイックスタートを確認してください Tutorial

1
maasha

このライブラリがあなたの質問への答えだと思います

beanのすべての初期値、setters、getters、hashCode(), equals() and toString()をテストします。あなたがしなければならないのは、デフォルトと非デフォルトのプロパティ/値のマップを定義することだけです。

また、デフォルト以外のコンストラクタが追加されたBeanであるオブジェクトをテストすることもできます。

1
Franck Valentin

プロパティごとにテストケースを作成するのではなく、リフレクション/イントロスペクターを使用してタイプを決定する単一のテストケースですべてのセッター/ゲッターをテストします。これは、これを示す優れたリソースです。

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unit_test_getters.html

0
Zim

私の評判のため、 @ me で前のコメントに答えます：

Vlookward、ゲッター/セッターを記述しないことはまったく意味がありません。プライベートフィールドを設定するための唯一のオプションは、明示的なセッターを使用するか、コンストラクターでセッターを設定するか、または他のメソッドを介して間接的に設定する（機能的にセッターを別の場所に延期する）ことです。セッターを使用しないのはなぜですか？

まあ、時々、フィールドがプライベートである必要はありません（私の英語があまり上手くなければ申し訳ありません）。多くの場合、ソフトウェアをライブラリとして作成し、フィールド（ビジネスロジックフィールド）を不要なゲッター/セッターでカプセル化します。

また、その方法が実際に必要な場合もあります。次に、2つの可能性があります。
1。それらの中にビジネスロジックがあります。次に、それらはテストされるはずですが、実際のゲッター/セッターではありません。私はいつもそのロジックを他のクラスで書いています。テストでは、[〜＃〜] pojo [〜＃〜]ではなく、他のクラスをテストします。
2。存在しない。その後、できれば手で書かないでください。たとえば、次のインターフェイスの実装は完全に自動生成される場合があります（実行時にも自動生成されます）。

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

だから、手書きで書かれたものだけをテストしてください。ゲッター/セッターかどうかは関係ありません。

0
Daniel Fanjul