@Entityで注釈が付けられたPojoをテストする必要があるかどうかわかりません。結局のところ、主に生成されたゲッター/セッターがあります。それらをテストする必要がありますか?
DAOのテストに関しては、これらすべてのエンティティを使用しているので、すでに適切にテストされていると思いますか?
あなたの考えをありがとう。
マット
@Entityで注釈が付けられたPojoをテストする必要があるかどうかわかりません。結局のところ、主に生成されたゲッター/セッターがあります。それらをテストする必要がありますか?
DAOのテストに関しては、これらすべてのエンティティを使用しているので、すでに適切にテストされていると思いますか?
あなたの考えをありがとう。
マット
コードにバグを含めることはできますか?そうでない場合、それをテストすることのポイントは何ですか?実際、テストしようとすると、新しいバグが発生するだけです(テストが間違っている可能性があるため)。
したがって、結論は次のとおりです。コードなしでゲッターとセッターをテストしないでください(つまり、追加のコードなしでフィールドを割り当てたり読み取ったりするだけのもの)。
例外は次のとおりです。タイプミスをした可能性があるため、これらのゲッター/セッターを手動で作成する場合。しかし、それでも、一部のコードはこれらを使用し、そのコードのテストが必要です。これにより、ゲッター/セッターが正しく動作するかどうかがテストされます。
書き込みテストについて考えられる唯一の理由は、@Entity アノテーション自体をテストすることです。値の保存と取得をテストすることは、プログラミング環境の基本的な能力を疑っているようです:)