ゲッターとセッターを自動テストする Java 単体テストフレームワークはありますか?[閉まっている]

https://stackoverflow.com/questions/108692

01-07-2019
|

質問

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

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

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

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

解決

ユニットこれを静的メソッドで実行します assertRefEquals.

他のヒント

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

ゲッターとセッターの自動テストがコードの品質やカバレッジに利益をもたらすかどうかは疑問です。これらのメソッドは他のコードから使用されます (そしてそこでテストされます。100% カバーされているか、まったく使用されていない (削除される可能性がある)。最終的に、ゲッターとセッターはテストから使用され、アプリケーションの他の場所では使用されないため、そのまま残しておきます。

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

私が作成したのは、オープンポジョそれを解決するためのプロジェクト ちょうど 問題。

プロジェクトを使用すると、以下を検証できます。

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

チュートリアルを参照

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

null値は可能ですか?
空の文字列は可能ですか?
それとも負の値ですか？
それともゼロ値？
それともリストの値は有効ですか?
それとも最大値はあるのでしょうか？
それとも BigDecimal 値に最大精度はありますか?

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

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

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

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

getter メソッドと setter メソッドはできる限り避けるべきだと思いますが、それらが存在し、テストに 2 行かかる限り、そうするのは良いことです。

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

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

すべての Bean の初期値をテストします。 setters, 、 getters, hashCode(), equals() and toString(). 。必要なのは、デフォルトとデフォルト以外のプロパティ/値のマップを定義することだけです。

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

openpojoを試しています

タイヤを蹴りましたが、うまく機能しているようです。

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

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

前のコメントへの返信 @自分私の評判のせいでここにいます：

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

まあ、場合によっては、フィールドを非公開にする必要がないこともあります (私の英語があまり上手ではない場合は、申し訳ありません)。多くの場合、私たちはソフトウェアをライブラリであるかのように作成し、フィールド (ビジネスロジックフィールド) を不要なゲッター/セッターでカプセル化します。

また、そのメソッドが実際に必要な場合もあります。その場合、次の 2 つの可能性があります。
1.それらの内部にはビジネスロジックがあります。その後、それらはテストされることになりますが、それらは本当のゲッター/セッターではありません。私はいつもそのロジックを他のクラスで書きます。そして、テストは他のクラスをテストします。 ポジョ.
2.存在しない。そして、できれば手書きで書かないでください。たとえば、次のインターフェイスの実装は完全に自動生成される場合があります (実行時にも!)。

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

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

各プロパティのテストケースを作成するのではなく、リフレクション/イントロスペクターを使用して 1 つのテストケースですべてのセッター/ゲッターをテストし、型を決定します。これを示す素晴らしいリソースは次のとおりです。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow

ゲッターとセッターを自動テストする Java 単体テスト フレームワークはありますか?[閉まっている]

ゲッターとセッターを自動テストする Java 単体テストフレームワークはありますか?[閉まっている]