web-dev-qa-db-ja.com

POJOのJUnitテスト

私はすべてのシンプルBean（POJO）の単体テストを作成する必要があるプロジェクトに取り組んでいます。 POJOの構成要素がすべてゲッターとセッターだけの場合、POJOの単体テストを作成する意味はありますか？ POJOがほぼ100％の時間で機能すると想定しても安全ですか？

重複- @ Entity Pojosをテストする必要がありますか？

も参照してください

偽のリポジトリではなくDBでテストを実行することは悪い習慣ですか？

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

javajunitpojo
27
Ryan Thames

TDDのルールは "壊れる可能性のあるすべてをテストする" ゲッターは壊れますか？一般的にはそうではないので、私はそれをテストする気になりません。さらに、コードIdoテストは確実にゲッターを呼び出すので、willテストされる。

私の個人的なルールは、私が決定を下すか、ささいな計算以上のものを実行する関数のテストを書くことです。私は_i+1_のテストを記述しませんが、おそらくif (i<0)...をテストし、確実に_(-b + Math.sqrt(b*b - 4*a*c))/(2*a)_をテストします。

ところで、POJOを強調することには、その背後に別の理由があります。 それらが実行される環境に依存しないPOJOに書き込まれた膨大な量のコードが必要です。たとえば、サーブレットはコンテナ内での実行に依存しているため、サーブレットのテストは困難です。したがって、サーブレットが環境に依存せず、テストが容易なPOJOをサーブレットから呼び出す必要があります。

40
Uncle Bob

単純なプロパティのゲッターとセッターをテストする意味はないと思います。単体テストの目的は、コンパイラが動作することを確認することではありません。

ただし、条件付き、nullチェックなどの重要な動作をゲッターとセッター（またはその他のメソッド）に追加したらすぐに、単体テストを追加するのが適切だと思います。

11
David Carlson

次のような理由で、私はかつて2時間過ごしました。

int getX()
{
    return (x);
}

int getY()
{
    return (x); // oops
}

単純なゲッターのテストを書くのにほとんど時間はかからないので、今では習慣からそれを行います。

8
TofuBeer

私はIDEとしてIntelliJを使用しますが、それは私にとっては取るに足らないPOJOを作成します。私が書いているテストコードにはバグが含まれている可能性が高いため、これを単体テストすることには意味がありません。

4
Jon

IMHO POJOは、機能などのロジックがテストされると自動的にテストされます。関数をテストするために、特定の値、POJOをインジェクト/モックする必要がある場合があり、POJOのゲッター/セッターは間接的にテストされます。

ただし、特定のユースケースで単体テストのPOJOを排除するには、次の2つの方法で実現できます。

  1. USE LIBRARY：POJOのテストに役立つ既存のライブラリを使用します。私が出会ったそのようなライブラリーの1つは、meanbeanです。

    Ref： http://meanbean.sourceforge.net/

    Maven： http://mvnrepository.com/artifact/org.meanbean/meanbean （現在のバージョン：2.0.3）

  2. IJORE POJO：単体テストカバレッジレポートから除外するPOJOまたは特定のパッケージを除外するようにSonarを構成できます。以下のいくつかの例：

    <properties>
    <sonar.coverage.exclusions>
        **/domain/**/*,
        **/pojos/*
    </sonar.coverage.exclusions>
</properties>
1
Anamika

単体テストは、コードが適切に機能することを検証するだけでなく、予想される動作を文書化します。いつか、誰かがPOJOのゲッターまたはセッターの動作を変更し、それが予期せず何かを壊す（たとえば、誰かがセッターにロジックを追加する）ために、何回壊れたのかわかりません文字列にnull値を設定すると、セッターはそれを空の文字列に変更して、NPEが発生しないようにします。

データストアPOJOの単体テストは時間の無駄ではなく、将来のメンテナンスのためのセーフティネットと見なしています。そうは言っても、これらのオブジェクトを検証するためのテストを手動で記述している場合は、難しい方法です。 http://gtcgroup.com/testutil.html のようなものを見てください

1
user1742058

POJOのテストを可能にするオープンソースユーティリティ http://meanbean.sourceforge.net/ があります。このユーティリティが提供するものと、なぜそれを使用する必要があるのか​​についてのメリット/質問を説明するページもあります。

私自身は（まだ）疲れたことはありませんが、私には勧められています。

1
Saifuddin Merchant

私の答えは、簡単なゲッターとセッターは自分のテストに値しないということです。単純な読み取りまたは書き込み以外のコードを追加する場合は、テストを追加します。

もちろん、これはすべてボイラープレートなので、値があると思われる場合は、ゲッターとセッターの単体テストを生成するスクリプトを簡単に作成できます。特定のIDEでは、このボイラープレートコード用にテストメソッドが入力されたテストケースを作成するテンプレートを定義できる場合があります（ここではIntelliJを考えていますが、Eclipseでも処理できますが、どちらもこのようなことをしていません） IDE）。

1
Jeff

私の経験では、getterとsetterだけでPOJOの単体テストを作成することは、やりすぎです。もちろん、いくつかの例外があります。nullのチェックや何か特別なことを行うようなgetter/setterに追加のロジックがある場合は、そのための単体テストを作成します。

また、POJOにバグがある場合は、ユニットテストを作成して、それが再発しないようにします。

1
Theo

あなたが書いていないことを確認するための簡単なテストの価値があるでしょう

public void setX(int x) {
   x = x;
}

それを避けるためにコーディングする必要があります（メソッドパラメータにfinal修飾子を付けるなど）。また、アクセサーの生成方法や、コピー/貼り付けエラーなどが発生する可能性があるかどうかにも依存します（これは、IDEの使用を強制しようとする環境でも発生します）。

ただし、セッター/ゲッターを多く含むクラスに関する私の最大の懸念はクラスが何をしているですか？オブジェクトは、データを保持して返すだけでなく、何かを実行する必要があります。これらがデータエンティティオブジェクトの場合は、setter/getterパターンが正しい可能性があります。ただし、データを返して自分で実行するのではなく、オブジェクトにデータを設定し、オブジェクトにデータの処理（銀行残高の計算、ロケットの発射など）を依頼する方がよいパターンです。

1
Brian Agnew

コードカバレッジについてcobaturaを試してみたところ、同じ問題が発生しました。

このクラスをコードカバレッジに含めないようにクラスに追加する注釈があると便利です。ただし、pojoを別のパッケージに入れて、そのパッケージを分析から除外することは可能です。

お使いのツールに応じてドキュメントを参照してください。Ant、Maven、またはコマンドラインで動作します。

0
Chris

私はこれを行うためのプロジェクトを始めたところです。現在、プレアルファ段階にあります。 Eclipseプラグインです。

通常POJOセッター/ゲッターは必ずしもテストを必要としないことに同意しますが、状況が変化するにつれてPOJOのテストを簡単に追加できるようになるので、そこに単純なテストがあればいいと思います。 。ユニットテストが設定され、メソッドはセッター/ゲッターをテストするためにあります。新しい複雑さを処理するだけで済みます。

これは、コードカバレッジレポートにも役立ちます。これは、マネージャーを満足させるのに役立ちます。 （私の会社ではEmmaを使用しています）。

https://sourceforge.net/projects/unittestgplugin/

0
utcp-manager

この問題は、すべてのボイラープレートコードと、equalsおよびhashcodeを削除するLombokライブラリを使用することで解決できます。

したがって、イクスとハッシュコードに特定の要件がない限り、それらをテストする必要はありません

https://projectlombok.org/

0
Ciccio