0

現在の問題

関連記事を参照してください:休止状態のドメイン クラスで問題が発生する可能性があるため、それらを (単体) テストする必要がありますか? 私の新しい J2EE プロジェクトでは、書き始めたドメイン オブジェクトをテストしようとしています (必ずしも単体テストではありません)。それらはビジネス ロジックの多くを必要とせず (ビジネス ロジックは DAO オブジェクト上のビジネス サービスの一部です)、テストによって、ドメイン オブジェクトの整合性を本質的に保証しており、DAO をテストすることでそれを実行しようとしています。メソッド。私の場合、JUnitなどを使用してドメインオブジェクトをテストできないことに注意してください。私の場合、ドメインオブジェクトにはメソッドがなく、属性と休止状態のマッピングアノテーションがあるためです。

たとえば、Patientドメイン オブジェクトについて考えてみましょう。 この場合、 PatientDAOは、Patient ドメイン オブジェクトの CRUD 操作を処理します。メソッドは次のとおりです (完全ではなく、後で境界条件をテストするためにさらに追加する予定です)。

注: これらを単体テスト ケースと呼んでいるわけではありません。ミニ統合テストなどである可能性があります。このアプローチがドメイン オブジェクトのテストで機能することは問題ありません。

PatientDAOTest クラスには以下が含まれます。 - testCreatePatient(); -testUpdatePatient(); - testFindPatient(); -testDeletePatient();

PatientDAO クラスには以下が含まれます。 - createPatient(); - updatePatient(); - findPatient(); -deletePatient();

ドメインオブジェクトで updateMethod() をテストする testUpdatePatient() メソッドを考えてみましょう。では、testUpdatePatient() メソッドをどのように実装するのでしょうか? 1. 「findPatient()」ドメイン メソッドを使用して既存の患者を取得する 2. 新しい詳細で患者レコードを更新する 3. 「updatePatient()」ドメイン メソッドを使用してデータベースに保存し直す 4. 取得する'findPatient()' ドメイン メソッドを使用してデータベースから患者レコードを返す 5. 更新されたデータをアサートする

質問

ご覧のとおり、テストでデータベースを使用していますが、問題はありませんが、このアプローチに問題はありますか?

このアプローチに関する私の本当の質問 (問題として読む) は何ですか?

「 updatePatient ()」のテスト中に、「 findPatient ()」メソッドを (実際には 2 回)使用する必要があります。メソッドのテスト中に別のメソッドを使用しなければならないのに、別のメソッド自体にバグがある可能性があるという事実は、私が気に入らないことです。他の CRUD メソッドもテストしようとすると、同じ話が繰り返されます。

別の方法として、select sql クエリを記述して、データベースから患者レコードをフェッチし、(更新が起動された後に) テスト メソッドからアサートすることもできますが、(SQL コーディング作業を削減するために) 休止状態を使用する目的全体が無効になるだけです。したがって、私はこのアプローチが好きではありません。

私の質問は、特定のメソッドをテストするために他のメソッドに依存するのが一般的ですが、これは悪いアプローチではないですか? これが間違っている場合、ドメイン オブジェクトで ORM マッピングを実際にテストする方法を教えてください。

コメントありがとうございます。

4

1 に答える 1

1

私の経験によると、あなたの主な関心事への答えは簡単ですが、ここには他にもいくつかの概念的な問題があります。

  1. 別の機能 (updatePatient) の insede テストに機能 (findPatient) を使用することは完全に問題ありませんが、findPatient 自体を単独でカバーする別のテストがある場合に限ります。
  2. DB 統合テストの系統的な部分では、専用の自動テスト DB の使用を検討し、すべてのデータを消去して、ユニット テストのセットアップとして目的の状態に初期化します。純粋な SQL スクリプト (TRUNCATE TABLE Patients; INSERT INTO Patients ...) を使用して、サンプルの初期データで DB を初期化します。 」など）。ここでのポイントは、単体テスト中に DB が変更され、純粋な ROLLBACK を使用してテスト前の状態に入っても、必要な正確な状態が保証されないことです (たとえば、テスト中に明示的にコミットすると、データが初期状態とは別）。また、純粋な SQL を使用して、テストによって変更された後に DB の状態を保証するテストを含めることもできます。このアプローチを使用したテストは、通常、実行に時間がかかり、維持するのが困難ですが (独自のヘルパー ツールのセットがない限り)、データと動作に完全な自信が持てます。これを明確に行った後は、UI/機能テスト中の多くの時間と混乱を節約できます。ひどいように聞こえるかもしれませんが、少しいじってみると、単純な DB 状態データのセット (たとえば、テスト ケース内の TSV/CSV として表される) である「initState」と「expectedState」になり、これらを使用するだけです。テストされた動作の前後に初期化/比較する状態。UI/機能テスト中の多くの時間と混乱を節約できます。ひどいように聞こえるかもしれませんが、少しいじってみると、単純な DB 状態データのセット (たとえば、テスト ケース内の TSV/CSV として表される) である「initState」と「expectedState」になり、これらを使用するだけです。テストされた動作の前後に初期化/比較する状態。UI/機能テスト中の多くの時間と混乱を節約できます。ひどいように聞こえるかもしれませんが、少しいじってみると、単純な DB 状態データのセット (たとえば、テスト ケース内の TSV/CSV として表される) である「initState」と「expectedState」になり、これらを使用するだけです。テストされた動作の前後に初期化/比較する状態。
  3. ドメイン オブジェクト (DB と統合されていない) の真の単体テストを行うには、DAO/Repository/DataMapper クラスをモックする必要があります。たとえば、単純な List ジェネリック (createPatient がそれをリストに追加するなど) を使用します。
  4. ORM 自体 (独自の、サード パーティ、またはその拡張) の統合テストでは、ORM がどのように機能するかについて確信を持てるほど複雑なサンプル データ (必ずしもドメイン オブジェクトではない) を使用して、ポイント 2 の方法を使用します。動作します。たとえば、Microsoft Entity Framework は初期段階では非常に予測不可能な動作をしていたので、通常使用する機能の完全な統合テストを作成することで、ORM 自体のバグや問題のデバッグを回避し、さまざまな条件下で ORM が正確にどのように動作するかを示すことができます。
于 2013-11-11T15:15:53.467 に答える