私はバックエンドでさまざまな複雑さのデータベースによって駆動される多くのWebアプリケーションを扱っています。通常、ORMビジネス ロジックとプレゼンテーション ロジックから分離されたレイヤー。これにより、ビジネス ロジックのユニット テストがかなり簡単になります。個別のモジュールに実装でき、テストに必要なデータはオブジェクト モックを通じて偽造できます。
しかし、ORM とデータベース自体のテストには、常に問題や妥協が伴います。
長年にわたり、私はいくつかの戦略を試してきましたが、どれも完全に満足できるものではありませんでした。
既知のデータでテスト データベースをロードします。ORM に対してテストを実行し、正しいデータが返されることを確認します。ここでの欠点は、テスト DB がアプリケーション データベースのスキーマ変更に追従する必要があり、同期がとれなくなる可能性があることです。また、人工データに依存しているため、ユーザーの誤った入力によって発生するバグが明らかにならない可能性があります。最後に、テスト データベースが小さいと、インデックスの欠落などの非効率性が明らかになりません (最後の点は、ユニット テストの本来の用途ではありませんが、害はありません)。
本番データベースのコピーをロードし、それに対してテストします。ここでの問題は、特定の時点で本番データベースに何が含まれているかがわからない可能性があることです。データが時間の経過とともに変更された場合、テストを書き直す必要がある場合があります。
これらの戦略は両方とも特定のデータに依存しており、ユニット テストでは機能のみをテストする必要があると指摘する人もいます。そのために、次のような提案を目にしました。
- モック データベース サーバーを使用し、指定されたメソッド呼び出しに応じて ORM が正しいクエリを送信していることのみを確認します。
データベース駆動型アプリケーションのテストに使用した戦略はありますか? 最も効果的だった戦略は何ですか?
ベストアンサー1
私は実際にあなたの最初のアプローチをかなり成功裏に使用しましたが、あなたの問題のいくつかは解決できると思われる少し異なる方法で使用しました:
スキーマ全体とそれを作成するためのスクリプトをソース管理に保存して、チェックアウト後に誰でも現在のデータベース スキーマを作成できるようにします。また、ビルド プロセスの一部で読み込まれるデータ ファイルにサンプル データを保存します。エラーの原因となるデータが見つかった場合は、そのデータをサンプル データに追加して、エラーが再発しないことを確認します。
継続的インテグレーション サーバーを使用して、データベース スキーマを構築し、サンプル データをロードして、テストを実行します。これが、テスト データベースを同期させる方法です (テストを実行するたびに再構築します)。これには、CI サーバーが専用のデータベース インスタンスにアクセスして所有権を持っている必要がありますが、データベース スキーマを 1 日に 3 回構築することで、配信直前 (またはそれ以降) まで発見されなかった可能性のあるエラーの検出が大幅に改善されたと言えます。コミットの前にスキーマを再構築しているとは言えません。誰かやっている人はいますか? このアプローチでは、その必要はありません (そうすべきかもしれませんが、誰かが忘れても大した問題ではありません)。
私のグループでは、ユーザー入力はアプリケーション レベル (DB レベルではない) で行われるため、標準の単体テストでテストされます。
本番データベースのコピーの読み込み:
これは、私の前職で使用されていたアプローチです。いくつかの問題があったため、非常に面倒でした。
- コピーは製品版より古くなってしまう
- 変更はコピーのスキーマに対して行われ、実稼働システムには反映されません。この時点で、スキーマが分岐することになります。これは楽しいことではありません。
モック データベース サーバー:
現在の仕事でもこれを行っています。コミットするたびに、モック データベース アクセサーが挿入されたアプリケーション コードに対して単体テストを実行します。その後、1 日に 3 回、上記の完全なデータベース ビルドを実行します。どちらのアプローチも絶対にお勧めです。