SQL Serverの単体テストと、VSTSを使用したCI/CDが必要な新しいプロジェクトがあります。
以下は必要な機能です
ストアドプロシージャに対するSQLServerユニットテスト、各テストの初期ターゲットテーブルのセットアップ、およびクリーンアップ
SQLでのユニットテスト
VSTSとGitを備えたCI/CD
簡単なセットアップと使いやすさ
SSDT 2017を調べましたが、これは良さそうです。ただし、プレテストステップの各テスト間で共通のセットアップスクリプトを簡単に共有できる機能が不足しているようです。日常的に使用できるはずの他の機能が不足している可能性があります。しかし、私は間違っているかもしれません。
2017年の一般的なSQLサーバーユニットテストに適したツールはどれですか?
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の利点に関するより詳細な記事を書きました。これも役立つかもしれません
スクリプトを再利用でき、多くのことができます。あなたの質問に対する簡単な答えは、tSQLtを使用することです。これまでのところ、tSQLtほど強力で柔軟性があり、使いやすいSQLServerの単体テストフレームワークは他にありません。使い始めるだけで、それだけです。 [〜#〜] ssdt [〜#〜]でセットアップするのは非常に簡単で迅速です。 @ datacentricityは、そのフレームワークについて十分に説明しています。詳細を知りたい場合は、彼が提供した記事を読んでください。
tSQLtの方向に進む場合は、生活を少し楽にするためにいくつか追加します。
他にも微妙な違いがあるかもしれませんが、何かから始めれば、すぐにtSQLtを愛し始めると確信しています。
Microsoftが推進していることに注意してください slacker 、例えばを参照してください。 チャネル9:DevOpsパイプラインでのSQL Serverデータベースユニットテスト 。 AzureSQLのセットアップで適切に機能することがわかりました。 Azure SQL上のtSQLtの場合、CLRおよびTRUSTWORTHYオプションの有効化に関するいくつかの問題を覚えていますが、それでも機能するはずです。ここに: