問題タブ [tsqlt]

tsqlt を使用するには、CLR 関数を有効にする必要があることがわかりました。実際に PDW で使用できますか?

または、PDW で単体テストを実行する他の方法やツールはありますか?

ありがとう、

SQL Server 単体テストに tSQLt を使用することを検討していますが、その前に、セットアップで作業しようとして時間を無駄にするかどうかを理解する必要があります。私がこれを尋ねる理由は、2 つのデータベースがあるためです。1 つはかなり「通常の」(本番データベース) で、もう 1 つはストアド プロシージャを介してこのデータベースへの制限付きアクセスを提供する「API」データベースです。 " API データベースにアクセスするユーザー アカウントと、本番データベース用の偽装アカウントの間。本番データベースのテーブルには、直接アクセスするのではなく、シノニムを介してアクセスします。トランザクションのプロビジョニングは、API データベースの「エントリ ポイント」ストアド プロシージャから行われます。

テストできるようにしたい主なことが 2 つあります。

(1) ビルド間でセキュリティ アクセスを正しく設定するのを「忘れる」と、共有オブジェクトを操作するときに問題が発生する可能性があるため、オブジェクトのセキュリティ アクセス許可。

(2) API ストアド プロシージャ/関数。一部の関数は比較的独立してテストできると思いますが、ストアド プロシージャがどのように簡単に機能するかわかりません。

• tSQLt はセキュリティ権限のテストをサポートしていますか?
• クロス データベース テストとシノニムに問題があることがわかりますが、情報はかなり歴史的なものです。これらは現在解決されていますか?
• tSQLt に CLR アクセス許可が必要なのはなぜですか?
• tSQLt「コード」は、テスト対象のデータベースにインストールする必要がありますか、それとも同じインスタンスのデータベースに対して実行できますか?
• リスト項目

私はhttp://www.sommarskog.se/share_data.htmlと tSQLt ドキュメントの知恵に従うために最善を尽くしてきました。簡単にテストできるように、ストアドプロシージャを軽量で比較的単純なものにしようとしています。そのため、プライマリストアドプロシージャで一時テーブルを作成し、プライマリストアドプロシージャから呼び出される「セカンダリ」ストアドプロシージャでその一時テーブルを操作していることに気づきました。これはかなりうまく機能しますが、テストするのは少し面倒です。

「セカンダリ」ストアド プロシージャを単独でテストする場合は、一時テーブルが既に存在している必要があります。プロシージャで一時テーブルを作成して[Set Up]も単体テストには保持されないようですが、完全なテーブルを作成すると保持されます。

CREATE TABLE #tempしたがって、すべての単体テスト (完全な列定義) を繰り返さないようにするために、次のバリエーションを実行しています。

一時テーブルを介してストアド プロシージャ間でデータを共有することで tSQLt を調整するより良い方法はありますか?

データベースの単体テストの作成を開始したところです。

私がテーブルを偽造した場合、

偽物かどうか確認できますか？

FakeTable SP に関するドキュメントは、ここにあります。

動機

テストを実行できるように、これらの偽のテーブルにデータを入力するいくつかのストアド プロシージャを作成することを想像しているので、これを実行できるようにしたいと考えています。ただし、ストアドプロシージャでテーブルの偽造を処理したくありません(そのため、毎回異なる情報を入力して複数回呼び出すことができます)。

データを追加する前にテーブルを偽造するのを忘れる可能性は望んでいません (ほぼ確実にテストに失敗する可能性があります)。