web-dev-qa-db-ja.com

TSQLユニットテストツール2017：SQLServerデータツール2017とtSQLt

SQL Serverの単体テストと、VSTSを使用したCI/CDが必要な新しいプロジェクトがあります。

以下は必要な機能です

  • ストアドプロシージャに対するSQLServerユニットテスト、各テストの初期ターゲットテーブルのセットアップ、およびクリーンアップ

  • SQLでのユニットテスト

  • VSTSとGitを備えたCI/CD

  • 簡単なセットアップと使いやすさ

SSDT 2017を調べましたが、これは良さそうです。ただし、プレテストステップの各テスト間で共通のセットアップスクリプトを簡単に共有できる機能が不足しているようです。日常的に使用できるはずの他の機能が不足している可能性があります。しかし、私は間違っているかもしれません。

2017年の一般的なSQLサーバーユニットテストに適したツールはどれですか？

VisualStudio用のSQLServerデータツール

[〜＃〜] tsqlt [〜＃〜]

sql-servervisual-studiosql-server-data-toolstsqltsql-server-unit-testing
9
Pingpong

SQL開発用の単体テストソリューションが他にない理由の1つは、データベースでは適切な単体テストが本質的に難しいため、人々がそれを行わないためです。これは、データベースが状態と参照整合性を維持するためです。 order_detail_update_statusテーブルのステータスフラグを更新するストアドプロシージャ（order_detail）の単体テストを作成することを想像してみてください。 order_detailテーブルはorder_headerテーブルとproductテーブルに依存し、order_headerはcustomerとemployeeへの外部キーを持ちますが、productテーブルはproduct_category、product_type、supplierに依存する場合があります。これは、1つのテストを作成するためだけに有効なデータを入力する必要がある少なくとも7つのテーブル（おそらくそれ以上）であり、これらのテーブルの1つを除くすべてがテスト対象のコードとは関係ありません。

したがって、単体テストソリューションで探す必要があるのは、最小限のセットアップで、コードの個別のユニットをテストする機能です。したがって、理想的には、必要なテストデータをorder_detailに設定し、残りのテーブルを無視することができます。これを可能にするテストフレームワークは1つだけです。

さらに、単体テストが失敗する理由は最小限である必要があります。上記の例では、order_detail_update_statusはorder_detailテーブルの1つの行を更新するだけです。テストセットアップで処理されない新しい非null列がcustomerテーブルに追加された場合、まったく関係のない理由でテストが失敗する可能性があるシナリオがあります。これは非常に脆弱なテストになり、厳しい納期のプレッシャーの下で、開発者はテストの作成と保守をすぐに諦めます。

一連の単体テストは、相互依存性なしで任意の順序で実行可能である必要があり、優れたテストフレームワークは、セットアップ、破棄、およびモックオブジェクトのサポート（同じフレームワークの一部である場合とそうでない場合があります）とともにこれをサポートする必要があります。上記のシナリオでは、order_detailテーブルをモックして、order_detailテーブルにのみ触れるモジュールをテストする機能は、失敗したテストの修正に膨大な時間を費やしたくない場合の最も重要な機能の1つです。 「理由。

したがって、要件と上記の点に関して、私が認識しているフレームワークは1つだけであり、これをすべて実行します- tSQLt 。これは実際の経験に基づいています。前回のプロジェクトで6,000を超えるtSQLtユニットテストを行いました。これには、次の機能が含まれます。

  • 単体テストのストアドプロシージャ、関数、およびビュー
  • 模擬テーブル、ビュー、関数
  • モック（またはスパイ）ストアドプロシージャ-分離、再生、または事前定義された結果のいずれか
  • スイートのセットアップ
  • 自動分解（すべてのテストは独自の翻訳で実行されるため）
  • ユニットテストは完全に分離されており、任意の順序で実行できます

CI/CDのVSTSで非常にうまく機能し、すべての単体テストはT-SQLで記述されているため、非常に使いやすいです。

Visual StudioでtSQLtを使用する最良の方法は、複合プロジェクトを利用することです。この場合、アプリケーションデータベースオブジェクトとモジュールは1つのプロジェクトで維持され、tSQLtフレームワークとすべての単体テストは2番目のプロジェクトの一部です。これを始めるのに良いアティクルがあります ここ 。

数年前の Simple-Talk のtSQLtの利点に関するより詳細な記事を書きました。これも役立つかもしれません

19
datacentricity

スクリプトを再利用でき、多くのことができます。あなたの質問に対する簡単な答えは、tSQLtを使用することです。これまでのところ、tSQLtほど強力で柔軟性があり、使いやすいSQLServerの単体テストフレームワークは他にありません。使い始めるだけで、それだけです。 [〜＃〜] ssdt [〜＃〜]でセットアップするのは非常に簡単で迅速です。 @ datacentricityは、そのフレームワークについて十分に説明しています。詳細を知りたい場合は、彼が提供した記事を読んでください。

tSQLtの方向に進む場合は、生活を少し楽にするためにいくつか追加します。

  • すべてのデータベース間またはリンクされたオブジェクトに同義語を使用します。
  • [〜＃〜] ssms [〜＃〜]の標準スクリプトを使用して、すべてのtSQLtオブジェクトを作成し、オブジェクトをインポートします[〜＃〜] ssdt [〜＃〜]に
  • tSQLtオブジェクト用に別のプロジェクトを作成し、テストするデータベースと「同じデータベース」としてマークします。
  • tSQLtプロジェクトでpre-scriptを作成し、originalデータベースプロジェクトのpre-scriptを実行しますそこから
  • tSQLtプロジェクトでポストスクリプトを作成し、元のデータベースプロジェクトのポストスクリプトを実行します。そこ
  • tSQLt post-scriptの最後のステートメントとして、「EXEC tSQLt.RunAll」と記述します。
  • tSQLtプロジェクトで公開スクリプトを作成し、設定で「拡張プロパティ」をデプロイすることを確認します
  • すべてのテストクラス（スキーマ）に拡張プロパティステートメントがあることを確認してください

他にも微妙な違いがあるかもしれませんが、何かから始めれば、すぐにtSQLtを愛し始めると確信しています。

3
Dmitrij Kultasev

Microsoftが推進していることに注意してください slacker 、例えばを参照してください。 チャネル9：DevOpsパイプラインでのSQL Serverデータベースユニットテスト 。 AzureSQLのセットアップで適切に機能することがわかりました。 Azure SQL上のtSQLtの場合、CLRおよびTRUSTWORTHYオプションの有効化に関するいくつかの問題を覚えていますが、それでも機能するはずです。ここに：

0
Triamus