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

Question

些細な getter/setter メソッドをテストする必要があるかどうかについて、Java (およびその他のコミュニティでは確かに) でよく知られている議論があります。通常、これはコードカバレッジに関するものです。これは開かれた議論であり、ここで答えようとしないことに同意しましょう。

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

そのような機能を提供するフレームワーク (jUnit など) はありますか? たとえば、「このテスト T は、クラス C のすべてのゲッター/セッターを自動テストする必要があります。それらは標準であると主張するからです」という注釈。

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

score 17 · Accepted Answer

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

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

Pojo コーディング標準を強制します (つまり、すべてのフィールドがプライベートである、またはネイティブ変数がない、など)。
Pojo の動作を強制する (つまり、setter は設定のみを行い、変換を行わないなど)
Pojo ID を検証する (つまり、アノテーションベースの等価性とハッシュコード生成を使用する)

チュートリアルを見る

score 14 · Accepted Answer

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

ゲッターとセッターの自動テストがコードの品質やカバレッジにメリットがあるとは思えません。これらのメソッドが他のコードから使用されている (そしてそこでテストされている、例えば 100% カバーされている) か、まったく使用されていない (そして削除される可能性がある) かのどちらかです。最後に、ゲッターとセッターはテストから使用されますが、アプリケーションの他の場所では使用されないため、残します。

このようなテストは、たとえば Apache Commons BeanUtils を使用して簡単に作成できるはずですが、それ以外に優れたテストがある場合は、本当にそれが必要かどうかは疑問です。

score 9 · Accepted Answer

9

Unitilsは、静的メソッドを使用してこれを実行しますassertRefEquals。

于 2008-09-21T00:19:48.457 に答える

score 7 · Accepted Answer

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

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

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

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

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

score 5 · Accepted Answer

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

ゲッターメソッドとセッターメソッドはできるだけ避けるべきだと思いますが、それらが存在し、テストに 2 行かかる場合は、そうするのが良いことです。

score 3 · Accepted Answer

コードカバレッジよりも OO 設計を優先し、それらのフィールドを必要なクラスに移動できないかどうかを確認します。したがって、前に提案したように、これらのゲッターとセッターを削除できるかどうかを確認しようとします。ゲッターとセッターはカプセル化を破っています。

score 2 · Accepted Answer

私はopenpojoを試しています

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

プロジェクト内のすべての pojo を確認できます。
pojoのベストプラクティスをチェックしているようです

クイックスタートチュートリアルについては、このチュートリアルを確認してください

score 1 · Accepted Answer

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

Bean のすべての初期値、、、をテストしsettersます。デフォルトおよび非デフォルトのプロパティ/値のマップを定義するだけです。gettershashCode(), equals() and toString()

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

score 0 · Accepted Answer

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

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

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

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

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

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

score 0 · Accepted Answer

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

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

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

10 に答える 10

Related

Reference

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