データベースの単体テストを行う方法
データベースを使用するアプリケーションを開発するときは、データベースの単体テストを行う必要があると聞きました。データベース単体テストのベストプラクティスは何ですか？ db単体テストを行う際の主な懸念は何ですか？また、それを「正しく」行う方法は何ですか？
データベース単体テストのベストプラクティスは何ですか？
DbUnit フレームワーク（データベースを既知の状態にし、そのコンテンツに対してアサーションを実行できるテストフレームワーク）には、データベーステストをリストするページがあります ベストプラクティス それは、経験、真実です。
DB単体テストを行う際の主な関心事は何ですか
- 最新のスキーマの作成、スキーマの変更の管理
- データ（参照データ、テストデータ）およびテストデータの維持のセットアップ
- テストを独立させる
- 開発者が同時に作業できるようにする
- 速度（データベースを含むテストは通常遅くなり、ビルド全体の時間が長くなります）
そしてそれを「正しく」行う方法は？
示唆されているように、既知のグッドプラクティスに従い、専用のツール/フレームワークを使用します。
- 可能であればメモリデータベースを優先する（速度のため）
- 開発者ごとに1つのスキーマを使用する必要があります（同時作業を可能にするため）
- 「データベース移行」ツール（RoR）を使用して、スキーマの変更を管理し、スキーマを最終バージョンに更新します
- 各テストの前にデータベースを既知の状態にし、実行後にデータに対してアサートを実行できるようにする（またはテストの最後にロールバックするトランザクション内でテストを実行できる）テストハーネスを構築または使用します。
データベース単体テストを開始する際に確認および検討する必要があるアイテムのリスト
- 他のテスター/開発者の活動を妨げることを避けるために、各テスターには個別のデータベースが必要です。
- テスト対象のデータベースを作成する簡単な方法を用意する（これは、SQL Serverデータベースをバージョン管理下に置くことに関連しています）。これは、一部のテストが失敗した場合に何がうまくいかなかったかを見つけようとするときに特に便利です。
- 一度にすべてをカバーするのではなく、特定の領域に焦点を合わせ、単一のモジュールのテストを作成します。テストをきめ細かく追加することは効率的な方法です
- デバッグを容易にするために、テストが失敗したときにできるだけ多くの詳細を提供するようにしてください
- すべてのテストに同一のテストデータを使用する
テストがtSQLtフレームワークを使用して実装されている場合、複数のSQL Serverインスタンスからの多くのデータベースを扱う場合、ユニットテストプロセスは複雑になる可能性があります。 SQL Server Management Studioから単体テストを直接保守、実行、管理するために、 ApexSQL単体テスト をソリューションとして使用できます
このリンク をご覧ください。 SQL Serverで単体テストストアドプロシージャを作成するためのいくつかの基本と、さまざまな種類の単体テスト、およびそれらをいつ使用するかについて説明します。使用しているDBMSがわかりませんが、明らかにこの記事はSQL Serverを対象としています。
記事から盗まれた：
機能テスト
最も一般的な最初のクラスのデータベース単体テストは、機能テストです。私の考えでは、機能テストは、データベースコンシューマーの観点からデータベースのコア機能（または、必要に応じてAPI）をテストします。ここでは、データベースのプログラマビリティオブジェクトをテストすることが主なシナリオです。したがって、データベース内のすべてのストアドプロシージャ、関数、およびトリガーをテストすることは、私の心の中で機能テストを構成します。ストアドプロシージャをテストするには、ストアドプロシージャを実行し、期待される結果が返されたか、適切な動作が発生したことを確認します。ただし、これらのタイプのオブジェクト以上のものをテストできます。たとえば、ビューが計算列から適切な計算を返すようにしたいことを想像できます。ご覧のとおり、この領域での可能性は大きいです。
スキーマテスト
データベースの最も重要な側面の1つはそのスキーマであり、データベースが期待どおりに動作することを確認するテストは、データベース単体テストの別の重要なクラスです。ここでは、ビューが適切なデータ型の予想される列のセットを適切な順序で返すようにすることがよくあります。実際には、データベースに期待どおりの1,000個のテーブルが含まれていることを確認したい場合があります。
セキュリティテスト
今日の時代では、データベース内に保存されているデータのセキュリティは重要です。したがって、データベース単体テストの別の重要なクラスは、データベースセキュリティをテストするクラスです。ここでは、データベースに特定のユーザーが存在し、適切な権限が割り当てられていることを確認する必要があります。多くの場合、制限されたテーブルまたはビューからデータを取得し、アクセスが適切に拒否されることを確認するネガティブテストを作成する必要があります。
ストックデータテスト
多くのデータベースには、在庫データまたはシードデータが含まれています。このデータはめったに変更されず、多くの場合、アプリケーションまたはエンドユーザーのルックアップデータとして使用されます。郵便番号とそれに関連する都市および州は、この種のデータの優れた例です。したがって、在庫データが実際にデータベースに存在することを確認するテストを作成すると便利です。
一般的なテストではなく、単体テストについてお問い合わせいただきありがとうございます。
データベースには、テストする必要のある多くの機能があります。いくつかの例：
- データ型/サイズ/文字セット（スウェーデン語の名前、または実際の世界からの長いURLまたは数字を挿入して、列の定義が正しいかどうかを確認してください）
- トリガー
- 制約（外部キー、一意性...）
- ビュー（データが正しく含まれているか、除外されているか、変換されているか確認してください）
- ストアドプロシージャ
- UDF
- 許可
- ...
これは、データベース内の何かを変更するときだけでなく、dbmsをアップグレードするとき、または設定を変更するときにも役立ちます。
一般に、統合テストが行われます。これは、PHPまたはJava=いくつかの例外は、次の2つの理由により、問題を理解するのが難しくなります。
- 問題は、PHPコード、またはPHP構成、ネットワーク、または...
- SQLステートメントは、別のプログラミング言語に埋め込まれている場合、読み取りや変更が困難です。
したがって、私の意見では、複雑なデータベースには、SQLで記述された単体テストフレームワークを使用する必要があります（ストアドプロシージャとテーブルを使用）。その種のツールは広く使用されていない（したがって広くテストされていない）ため、慎重に選択する必要があります。たとえば、MySQLを使用している場合、次のツールを知っています。
- STK /ユニット http://stk.wikidot.com/stk-unit
- utMySQL http://utmysql.sourceforge.net/
Junit/nunit/etcを使用して、データベースユニットテストをJavaまたはc＃でコーディングします。これらは、おそらくテストデータベースとは別のスキーマを使用して、統合サーバーで実行できます。
最新のOracle SQL開発者には、単体テストフレームワークが組み込まれています。私はこれを調べましたが、[〜＃〜] not [〜＃〜]使用します。 GUIを使用してテストを作成および実行し、すべてのテストをデータベースに保存するため、テストケースをバージョン管理下に置くことはそれほど簡単ではありません。おそらく他のテストフレームワークがありますが、それらはデータベースに固有のものであると思います。
良い習慣は、通常の単体テストに似ています：
- テストをソース管理下に置く
- 高速で実行されるテストを作成する-一度にあまりテストしない
- テストを再現可能にする
DBTestDrivenフレームワークをご覧ください。それは私たちにとって素晴らしい作品です。 GitHubまたはそのWebサイトからダウンロードします。
JVM開発に関しては、ユニットテストはJDBC抽象化の恩恵を受けることができます。どのJDBCデータがDBアクセスによって発生するかを知るとすぐに、これらのJDBCデータを「再生」できます。
したがって、ターゲットDBなしで、テストのためにDBアクセスケースを「再現」できます。テスト/データ分離の複雑さはなく、継続的な統合が容易です。
私のフレームワークAcolyteは、この方法で役立つフレームワークです（DB結果を「記録」するスタジオGUIツールを含む）： https://github.com/cchantep/acolyte