10

testingに関する春のドキュメントでは、次のように述べています。

ORM コードのテスト時に誤検知を回避する

JPA や Hibernate などの ORM フレームワークを含むコードをテストする場合は、セッションの状態を更新するテスト メソッド内で基礎となるセッションをフラッシュします。ORM フレームワークの基礎となるセッションのフラッシュに失敗すると、誤検知が発生する可能性があります。テストは成功する可能性がありますが、ライブの本番環境では同じコードが例外をスローします。次の Hibernate ベースのサンプル テスト ケースでは、1 つのメソッドが誤検知を示し、もう 1 つのメソッドがセッションのフラッシュの結果を正しく公開しています。

フラッシュを呼び出す必要がある理由を誰かが説明できますか?

4

4 に答える 4

3

さて、あなたは実際に興味深い部分、例をスキップしました:)それは次のとおりです:

// ...

@Autowired
private SessionFactory sessionFactory;

@Test // no expected exception!
public void falsePositive() {
    updateEntityInHibernateSession();
    // False positive: an exception will be thrown once the session is
    // finally flushed (i.e., in production code)
}

@Test(expected = GenericJDBCException.class)
public void updateWithSessionFlush() {
    updateEntityInHibernateSession();
    // Manual flush is required to avoid false positive in test
    sessionFactory.getCurrentSession().flush();
}

// ...

この例が説明しようとしているのは、実際flushにセッション (別名、第 1 レベルのキャッシュ) でメモリ内の変更をデータベースと同期しない限り、実際にはデータベース統合をテストしていないため、実際に期待される動作をテストしていないか、失敗している可能性があるということです。問題。

たとえば、データベースは、たとえば制約違反が原因でエラーを返す可能性があり、データベースにヒットしない場合、falsePositive()上記のテスト方法のように、この正しい動作を示すことはありません。このテスト メソッドは失敗するか、例外が発生するはずですが、合格するだけです。一方、フラッシュを使用したもう 1 つのテスト メソッドは、実際の動作をテストします。したがって、する必要がありflushます。

于 2010-08-25T03:04:43.493 に答える
1
于 2014-05-15T09:06:05.567 に答える
1

Spring のドキュメントでは、間違った概念が使用されています。判明しました

しかし、ライブの本番環境では同じコードが例外をスローします

ウィキペディアはこちら

タイプ II の誤り。「第 2 種の誤り」、β 誤り、または「偽陰性」とも呼ばれます。帰無仮説が実際には真ではないのに、帰無仮説を棄却できない誤りです。この例としては、テストで女性が妊娠していないことが示され、実際には妊娠している場合が挙げられます。

Spring提供のサンプルを見ると、本番環境では例外(A GenericJDBCException)がスローされますが、検出されていません。確認するには、ORM プロバイダーを使用するときに、基になるコミットを呼び出す必要があります。

XUnit テスト パターンの定義

テスト対象のシステムが正常に動作していなくても、テストに合格する状況。

したがって、正しい概念は falseNegative です

@Test // no expected exception!
public void falseNegative() {
于 2010-08-25T04:15:13.357 に答える