単体テストに HSQLDB を使用しています。ORM レイヤーを明示的にモックせずに HSQLDB を使用しているときに、制約違反、ORM レイヤーの例外、完全なデータベースの停止など、さまざまなデータベースの問題をモックする良い方法はありますか?
2 に答える
停止の場合は、DB を開始しないようにすることができます。他のすべてのことについては、ORM レイヤーをモックすることをお勧めします。
ところで: HSQLDB を使用する場合、実際には単体テストではなくなります。それは統合テストのようなものです。
インメモリデータベースは実際には切断されたり、同様になったりしないため、これを行うのは非常に難しいようです。ただし、状況に応じていくつかのオプションがあります。
制約違反を偽装するには、制約を破る何かを行います。たとえば、一意の制約の場合は事前に重複行を追加し、外部キー制約の場合は、テスト対象のシステムが予期しない場合に参照された外部行を削除します。
ORM レイヤーの例外は注意が必要です。ここでなんらかの反応を得る最も簡単な方法 (たとえば、すべてのテーブルを削除する) は、おそらくデータベースに対してワイルドなことを行うことですが、考えられる問題の多くを再現するのに苦労することになると思います。
インメモリ データベースは常にアクセス可能であるため、DB の停止を直接偽装することはできません。解決策は、テスト対象のシステムとデータベースの間のレイヤーに入り、そこで接続を切断することです。私は現在、Spring および JDBC テンプレートを使用して Java プロジェクトでこれを行っており、DB のタイムアウトと停止をそれぞれ次のようにモックしています。
DriverManagerDataSource dataSource =
((DriverManagerDataSource)jdbcTemplate.getDataSource());
// 192.0.2.1 is in the TEST-NET range, guaranteed
// to never exist, so this always times out
dataSource.setUrl("jdbc:hsqldb:http://192.0.2.1/testdb");
// Subsequent operations then timeout
と
// Port 9 is reserved for 'discard', so is almost certainly unconnectable
// and very very unlikely to ever actually return valid data even if not.
dataSource.setUrl("jdbc:hsqldb:http://localhost:9/testdb");
// Subsequent operations immediately fail to connect
現在開いているすべての接続を切断する方法はないと私が知る限り、これらは両方とも新しい接続を切断することに注意してください。ただし、参照を取得できる場合は、close() を実行すると、飛行中の切断をシミュレートするのにかなり近くなるはずです。
また、boutta が指摘したように、これは単体テストではなく統合テストです。これらの統合テストを行うことに加えて、ここで DB と通信しているコードの単体テストを行い、そのためにデータベース インターフェイス (たとえば、JDBC テンプレート) を完全にモックアウトすることも必要になるでしょう。これにより、実際には多くのことがはるかに簡単になり、特に特定の例外シナリオのシミュレーションが容易になります。