単体テストとTDDを使用して、主にデータベースCRUD操作に依存するアプリをテストするにはどうすればよいですか？

仕事中、私のプロジェクトの1つは主に外部クライアントから渡されたデータを取得し、データベースに保持することです。JPAを使用するJavaエンタープライズアプリであり、ほとんどのロジックはCRUD操作を中心に展開します。

バグの大部分は、何らかの形でJPAに関係しています。

• 例1：[保存]ボタンを2回クリックすると、JPAは同じエンティティをデータベースに2回挿入しようとし、主キー違反が発生する場合があります。
• 例2：データベースからエンティティを取得し、編集して、そのデータを更新しようとします。JPAは、古いインスタンスを更新する代わりに、新しいインスタンスを作成しようとする場合があります。

多くの場合、ソリューションはJPAアノテーションを追加/削除/変更する必要があります。また、DAOロジックの変更に関係する場合もあります。

単体テストとTDDを使用してコードに自信を持たせる方法がわかりません。ユニットテストとTDDの適合性が悪いのか、問題に近づいているのかがわかりません。

単体テストは、実行時にしかこれらの問題を発見できず、問題を再現するためにアプリサーバーに展開する必要があるため、不適切なように見えます。通常、データベースは関与する必要がありますが、これは単体テストの定義の外側にあると考えられます。これらは統合テストです。

TDDは、展開とテストのフィードバックループが非常に遅いため、非常に非生産的であるため、不適切なように思われます。deploy + testフィードバックループには3分以上かかります。これは、作成中のコードに関するテストを具体的に実行した場合にのみ発生します。すべての統合テストを実行するには、30分以上かかります。

この型の外側にはコードがあり、できる限りいつでも単体テストを行っています。しかし、バグの大部分と最大のタイムシンクは、常にJPAまたはデータベースに関係しています。

同様の別の質問がありますが、アドバイスに従えば、コードの最も不安定な部分（JPA）をラップし、それ以外のすべてをテストします。私の質問の文脈では、私は同じ悪い状況にいるでしょう。JPAをラップした後の次のステップは何ですか？IMOその質問は（おそらく）私の質問に答えるためのステップですが、それに対する答えではありません。

1つのオプションは、H2などのメモリ内テストデータベースを使用することです。これは、標準のディスク使用データベースよりも約10倍高速で、起動/ティアダウン時間が短い傾向があります。

役立つかどうかは、お持ちのJPAの問題が一般的なものであり、別のデータベースで失敗するかどうかに大きく依存します。問題の大部分が見逃された場合、ポイント実行テストはそれほど速くありません。

しかし、システム全体でH2を使用して10回実行することができれば、成果を上げることができます。

データベースの単体テストは非常に簡単です。ストアドプロシージャとトランザクションが必要です。

これは、データベースの単体テストについてマイクロソフトが言ったことです。データベースに対してユニットテストを実行し、DB接続を設定してJavaまたはC＃でテストを作成し、トランザクションを開始し、テストに使用するデータをDBに書き込み、テストを実行してからロールバックすることもできます。デプロイしたDBを使用していて、完全に分離されたテストを取得した場合、DBに損傷はありません。

これにより、フレームワーク内でそれを行う方法についての洞察が得られることを願っています。

他の人々は「あなたのデータベースをモックアウト！」と答えました。-しかし、実際にコードとの相互作用をテストする必要がある場合、DBレイヤーをモックアウトするポイントは何ですか？

探しているのは、統合テストおよび/または自動化されたUIテストです。問題は次の場合に発生すると述べました。

*If you click the save button twice*

これをテストする唯一の方法は、ボタンを2回クリックする自動UIテストを作成することです。Seleniumをチェックしてください。

また、おそらくユニットテストDBが必要になりますが、テストではそれを示します。維持するのは苦痛ですが、現実の世界ではTDDを歓迎します。

質問の例では、ボタンを2回クリックして非常に簡単にエラーを引き起こす状況にユニットテスト/ TDDすることはできません。しかし、ユニットテストできるのは、ボタンをクリックしたときに呼び出されるコードで、永続化レイヤーから例外を取得した場合、適切に処理することです（永続化レイヤーをモックアウトするか、インメモリデータベースを他の回答で提案されています）-再スローするか、エラーを表示するか、または何でも。

ユニットテストに適さないテスト（統合/システムテストなど）を実行する必要がある場合、TDDが故障し始める可能性があることは確かです。これは、最近の「TDDはデッド？" ケント・ベック、マーティン・ファウラー、デビッド・ハイネマイヤー・ハンソン間の議論：http : //martinfowler.com/articles/is-tdd-dead/