0

ドメイン オブジェクトのロックを解除するために、次のような新しいエンドポイントを作成します。

../domainObject/{id}/unlock

TDD を適用するにあたり、まず API テストを書き始めました。テストが失敗したら、統合テストと単体テストを書き始め、実際のコードを実装します。

API テストでは、作成されるロック解除エンドポイントをテストするために、テスト フィクスチャ セットアップ用のロックされたドメイン データが必要です。ただし、システム上のドメイン オブジェクトをロックするためのエンドポイントはありません。(私たちの Quartz ジョブはデータをロックします) つまり、データベースを直接使用してデータを作成する必要があります。

API テストでは、単純にデータベースを使用することがベスト プラクティスではないことはわかっています。テスト データが必要な場合は、API も呼び出す必要があります。例えば

../domainObject/{id}/lock

この場合、このシナリオは例外であるべきですか? または、従うべき他の慣行はありますか？

ありがとう。

4

1 に答える 1

0

ここには良い習慣も悪い習慣もありません。データベースを含むシステムのエンド ツー エンドのテストをどれだけ重視するかがすべてです。

DB 部分のテストには、もう少しインフラストラクチャが必要になります。これは、テスト実行を高速化するためにメモリ内データベースを使用するか、開発環境に本格的な永続的なテスト DB をセットアップする必要があるためです。後者を行う場合、通常のテスト スイートよりも実行頻度が低いエンド ツー エンド テスト用に別のテスト スイートを用意することをお勧めします。そのシナリオでは、既存のテスト データが常に DB に存在し、ロックされたオブジェクトがその 1 つになる可能性があります。

これらすべてを気にしない場合は、データ ストアの抽象化 (リポジトリ、DAO など) をスタブして、既定のロックされたオブジェクトを返すことができます。

于 2016-06-27T11:54:00.263 に答える