java - POJO の JUnit テスト

Question

私は、すべての単純な Bean (POJO) の単体テストを作成する必要があるプロジェクトに取り組んでいます。POJO が getter と setter だけで構成されている場合、POJO の単体テストを作成する意味はありますか? POJO が約 100% の時間で動作すると仮定するのは安全な仮定ですか?

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

こちらもご覧ください

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

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

score 53 · Accepted Answer

TDD のルールは、「壊れる可能性があるものはすべてテストする」です。ゲッターは壊れますか? 一般的にはそうではないので、わざわざテストする必要はありません。その上、私がテストするコードは確かにゲッターを呼び出すので、テストされます。

私の個人的なルールは、決定を行う関数、または些細な計算以上の関数のテストを作成することです。のテストは書きませんがi+1、おそらく、if (i<0)...そして間違いなくのテストを書き(-b + Math.sqrt(b*b - 4*a*c))/(2*a)ます。

ところで、POJO に重点を置くことには別の理由があります。実行環境に依存しない大量のコードを POJO に記述したいと考えています。たとえば、サーブレットはコンテナ内での実行に依存しているため、テストが困難です。そのため、環境に依存せず、テストが容易な POJO をサーブレットで呼び出す必要があります。

score 19 · Accepted Answer

POJOには、equals（）、hashCode（）、compareTo（）、およびその他のさまざまな関数などの他の関数も含まれる場合があります。これらの機能が正しく機能していることを知っておくと便利な場合があります。

score 14 · Accepted Answer

私はかつてこのような何かのために2時間を過ごしました：

int getX()
{
    return (x);
}

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

簡単なゲッターのテストを書くのにほとんど時間がかからないので、今は習慣からやっています。

score 12 · Accepted Answer

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

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

score 4 · Accepted Answer

私は IntelliJ を IDE として使用しており、それは私のために簡単な POJO をほとんど作成します - 確かにコンストラクターとゲッター/セッターです。バグは私が書いたテストコードにある可能性が高いため、これを単体テストする意味はありません。

score 3 · Accepted Answer

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

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

score 1 · Accepted Answer

書いたことがないことを確認するための簡単なテストはおそらく価値があります

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

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

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

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

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

また、POJOにバグがある場合は、ユニットテストを作成して、再発を防ぐことができます。

score 1 · Accepted Answer

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

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

score 0 · Accepted Answer

コードカバレッジのために cobatura を試していますが、同じ問題に遭遇しました。

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

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

score 0 · Accepted Answer

これを行うためのプロジェクトを開始しました。現在プレアルファ段階です。Eclipse プラグインです。

通常、POJO セッター/ゲッターは必ずしもテストを必要としないことに同意しますが、時間の経過とともに状況が変化するにつれて、POJO のテストを簡単に追加できるようになるため、そこに簡単なテストがあると便利だと思います。 . ユニットテストがセットアップされ、setter/getter をテストするためのメソッドが用意されています。あとは、新しい複雑さを処理するだけです。

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

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

score -1 · Accepted Answer

知りたいユニットテストコードは機能します（もちろんテストされた状況で）。確実に機能するようにしたいだけのテストコードを単体テストしないでください。

あまり考えられないので、ちょっと確信したいだけです。

score -2 · Accepted Answer

ゲッターとセッターがIDEを使用して作成されている場合は、問題ないと思います。コードを入れるものは他にもあります。明らかに、POJOのシリアル化/逆シリアル化をテストします。

java - POJO の JUnit テスト

17 に答える 17

Related

Reference