50

データベースを使用するアプリケーションを開発する場合、データベースの単体テストを行う必要があると聞いたことがあります。

データベース単体テストのベスト プラクティスは何ですか? DB単体テストを行う際の主な懸念事項と、それを「正しく」行う方法は何ですか?

4

8 に答える 8

41

データベース単体テストのベスト プラクティスは何ですか?

DbUnitフレームワーク(データベースを既知の状態にし、そのコンテンツに対してアサーションを実行できるようにするテスト フレームワーク) には、私の経験では真実であるデータベース テストのベスト プラクティスをリストしたページがあります。

データベース単体テストを行う際の主な懸念事項は何ですか

  • 最新のスキーマの作成、スキーマの変更の管理
  • データ（参照データ、テストデータ）の設定とテストデータの保守
  • テストの独立性を保つ
  • 開発者が同時に作業できるようにする
  • 速度 (データベースを含むテストは通常​​遅く、ビルド全体に時間がかかります)

そして、それを「正しく」行う方法は？

示唆されているように、既知の優れたプラクティスに従い、専用のツール/フレームワークを使用してください。

  • 可能であればメモリデータベースを優先する（速度のため）
  • 開発者ごとに 1 つのスキーマを使用する必要があります (同時作業を可能にするため)
  • 「データベース移行」ツール (RoR 風) を使用して、スキーマの変更を管理し、スキーマを最終バージョンに更新します。
  • 各テストの前にデータベースを既知の状態にし、実行後にデータに対してアサートを実行できるようにするテスト ハーネスを構築または使用します (または、テストの最後にロールバックするトランザクション内でテストを実行します)。
于 2010-09-22T18:17:16.523 に答える
11

このリンクを見てください。SQL Server でストアド プロシージャの単体テストを作成するための基本事項の一部と、さまざまな種類の単体テストとそれらを使用する必要がある場合について説明します。どの DBMS を使用しているかはわかりませんが、明らかにこの記事は SQL Server を対象としています。

記事から盗んだ：

機能テスト

データベース単体テストの最初の、そしておそらく最も普及しているクラスは、機能テストです。私の考えでは、機能テストは、データベースの消費者の観点から、データベースのコア機能 (または、必要に応じて API) をテストします。ここでは、データベースのプログラマビリティ オブジェクトをテストすることがメインライン シナリオです。したがって、データベース内のすべてのストアド プロシージャ、関数、およびトリガーをテストすることは、私の考えでは機能テストを構成します。ストアド プロシージャをテストするには、ストアド プロシージャを実行し、予期した結果が返されたか、適切な動作が発生したかを確認します。ただし、これらの種類のオブジェクト以外もテストできます。たとえば、ビューが計算された列から適切な計算を返すことを保証したいことを想像できます。ご覧のように、

スキーマ テスト

データベースの最も重要な側面の 1 つはそのスキーマであり、期待どおりに動作することを確認するためのテストは、データベース単体テストのもう 1 つの重要なクラスです。ここで、ビューが適切なデータ型の期待される列のセットを適切な順序で返すことを確認したいことがよくあります。実際に、データベースに期待どおりの 1,000 個のテーブルが含まれていることを確認したい場合があります。

セキュリティテスト

今日の時代では、データベース内に格納されているデータのセキュリティは非常に重要です。したがって、データベース単体テストのもう 1 つの重要なクラスは、データベースのセキュリティをテストするものです。ここでは、特定のユーザーがデータベースに存在し、適切な権限が割り当てられていることを確認する必要があります。制限されたテーブルまたはビューからデータを取得し、アクセスが適切に拒否されていることを確認するネガティブ テストを作成したい場合がよくあります。

ストックデータテスト

多くのデータベースには、株式データまたはシード データが含まれています。このデータはめったに変更されず、多くの場合、アプリケーションまたはエンド ユーザーのルックアップ データとして使用されます。郵便番号とそれに関連付けられた都市と州は、この種のデータの良い例です。したがって、株式データが実際にデータベースに存在することを確認するためのテストを作成すると便利です。

于 2010-09-22T17:52:29.730 に答える
5

一般的なテストではなく、単体テストについて質問してよかったです。

データベースには、テストが必要な多くの機能があります。いくつかの例：

  • データ型/サイズ/文字セット (スウェーデン語の名前、または現実世界の長い URL または数字を挿入してみて、列の定義が適切かどうかを確認してください)
  • トリガー
  • 制約 (外部キー、一意性...)
  • ビュー (データが正しく含まれているか、除外されているか、変換されているかを確認してください)
  • ストアド プロシージャ
  • UDF
  • 権限
  • ...

これは、データベースで何かを変更するときだけでなく、dbms をアップグレードしたり、設定で何かを変更したりするときにも役立ちます。

通常、統合テストが行​​われます。これは、PHP や Java などのプログラミング言語でテスト スイートが作成され、テストがいくつかのクエリを発行することを意味します。しかし、何かが失敗したり、例外があったりすると、次の 2 つの理由から、問題を理解するのが難しくなります。

  • 問題は、PHP コード、PHP 構成、またはネットワークにある可能性があります。
  • SQL ステートメントが別のプログラミング言語に組み込まれている場合、その SQL ステートメントを読んだり変更したりするのは難しくなります。

したがって、私の意見では、複雑なデータベースの場合は、SQL で記述された単体テスト フレームワークを使用する必要があります (ストアド プロシージャとテーブルを使用)。この種のツールは広く使用されていない (したがって、広くテストされていない) ため、慎重に選択する必要があります。たとえば、MySQL を使用している場合、次のツールを知っています。

于 2013-05-22T11:21:36.377 に答える
3

junit/nunit/etc を使用し、データベースのユニット テストを Java または C# でコード化します。これらは、おそらくテスト データベースに対して別のスキーマを使用して、統合サーバー上で実行できます。

最新の oracle sql 開発者には、組み込みの単体テスト フレームワークが付属しています。私はこれを調べましたが、使用しませんでした。GUIを使用してテストを作成および実行し、すべてのテストをデータベースに保存するため、テストケースをバージョン管理下に置くのは簡単ではありません. おそらく他のテストフレームワークがあり、それらはデータベースに固有のものであると思います。

グッド プラクティスは通常の単体テストに似ています。

  • テストをソース管理下に置く
  • 高速に実行されるテストを作成する - 一度に多くのテストを行わないでください
  • テストを再現可能にする
于 2010-09-22T17:56:44.943 に答える
2

DBTestDriven フレームワークを見てください。それは私たちにとって非常にうまくいきます。GitHub または Web サイトからダウンロードします。

于 2014-11-07T21:56:27.240 に答える
1

JVM 開発に関しては、単体テストは JDBC 抽象化の恩恵を受けることができます。どの JDBC データが DB アクセスによって発生したかがわかるとすぐに、これらの JDBC データを「再生」できます。

したがって、DB アクセス ケースは、ターゲット DB なしでテスト用に「再現」できます。テスト/データ分離の複雑さがなく、継続的な統合が容易になります。

私のフレームワーク Acolyte は、このように役立つフレームワークです (DB 結果を「記録」するためのスタジオ GUI ツールを含む): https://github.com/cchantep/acolyte

于 2014-01-06T09:26:23.113 に答える