hibernate.jdbc.batch_sizeが50に設定されていると、例外時に単一の更新をテストできない

Question

セキュリティ上の脆弱性を修正する必要がありました。アプリケーションがDB内のデータを更新できず、db例外をキャッチし、そのエラーメッセージをカスタマイズします。

この修正をテストするには、updateListサービスを実行して応答を検証する必要がありますが、Hibernateではhibernate.jdbc.batch_sizeが50に設定されています。これは、更新クエリが正常に更新されるため、

以下に述べるように、sessionFactory.getCurrentSession（）.flush（）を置くことによってのみ修正をテストできます。

public void update(final List list) 
{ 
    sessionFactory.getCurrentSession().update(list);  
    sessionFactory.getCurrentSession().flush(); 

} 

他にも最適なソリューションはありますか？またはflush（）を実行すると、DB内でクエリやクエリが強制的に更新されますが、hibernate.jdbc.batch_size = 50;

Answer 1

"更新クエリが更新カウントが50に達したときにのみ、更新クエリがデータベースにヒットします"というメッセージは完全に真ではありません。また、トランザクションが終了するとdbにヒットします。

flushを追加できますが、パフォーマンスが低下することがあります（理由はhibernate.jdbc.batch_size=50）。

他の場所でキャッチしてみることをおすすめします。サーブレットの場合と同様にカスタムフィルタを追加します。そのような例外からあなたを別の場所に保存することもできます。 Hibernateでは、いつデータをdbにフラッシュするかを予測することは困難です。

Answer 2

他にも最適なソリューションはありますか？

はい。
単一のエラーケースを処理するには、本番環境での実際の実装を反映しない方法で実装を変更するべきではありません。
なぜですか？このテストの後、実動で期待される動作を得るためには、実装を元に戻すことを考えなければならないからです。
この特殊なケースをテストするたびにこれらの変更を行うことを忘れてはいけません。
そうしないと、アプリケーションが期待どおりに機能しなくなることがあります。
これは良い方法ではありません。

あなたのケースをテストするには、ユニットテストを書くことができます。
さらに、実際のデータベース呼び出しに必ずしも依存する必要はありません。

1. モックメッセージ内の機密情報を持つ例外を生成するオブジェクト：
   

   Iは、ユニットテストにこのアプローチを提案します。
   

2. 動作を記録します。呼び出されると、このモックオブジェクトは、メッセージ内の同様の機密情報を持つ例外をスローします。
   
3. テストするメソッドが呼び出されると、getに機密情報が含まれていないというエラーメッセージをアサートします。

---

この機能は定期的に、ターゲットから非常に近い環境でテストすることが非常に重要である場合は、本番（hibernate.jdbc.batch_size=50）内のアプリケーションと同じ制約を使用して統合テストを作成することができますデータベースに少なくとも50個のデータも挿入する必要があります。

もちろん、このテストでは時間がかかることがあり、CIツールでのみ自動的に呼び出される必要があります。