私が取り組んでいるプロジェクトの一部として、読み取り専用の DAO (Bill クラス) があります。プロジェクト自体は、データベースでまだ表されていない Bill の新しいインスタンスを作成してはならず、この Bill クラスの値を変更または更新してはなりません。そのため、Bill インスタンスの偶発的な変更を防ぐために、すべてのコンストラクターとプライベートであり、セッターはありません (Hibernate はデータベースからの請求書データを Bill インスタンスにマーシャリングするために使用され、パブリック コンストラクターとセッターの不足に悩まされることはありません)。
今質問に：
統合テストの一環として、私たちのプロジェクトはデータベースに表示されていない新しい請求書オブジェクトを決して作成しないという原則に違反する必要があります。テストの目的のためだけに、この原則に違反する最善の方法は何ですか?
リフレクション ベースのビルダー:私が提案した 1 つのアイデアは、リフレクション ベースのビルダーを使用して、Bill クラスのコードを変更する必要がないようにすることです。請求クラスが間違っているとすぐに特定されます。
パッケージ プライベート コンストラクター:私の上司が提案した代替案は、ビルダーが使用できるパッケージ プライベート コンストラクターを含めることです。これには、ビルダーが機能することを確認するためのテストが少なくて済み、単純であるという利点があります。ただし、これに対応するには、メイン コード ベースに明示的なコードが必要です。
私たちのどちらも、どちらの考えにもあまり熱心ではありません。だから私は、他の誰かが以前に同様の問題に対処しなければならなかったかどうか、そして彼らがどのように対処したか疑問に思っていました. 「アジャイル テスト: テスターとアジャイル チームのための実践ガイド」をよく読んでいますが、これまでのところ関連するものは見つかりませんでした。
注意。請求書は DAO の複雑な階層 (データベース内の外部キー制約を含む) の一部であるため、データベースと直接やり取りするほど単純ではありません。そのため、このような階層を迅速かつ簡単に作成し、このすべてのデータをデータベースに永続化できるビルダーが望ましいです。