SQL Server 単体テストに tSQLt を使用することを検討していますが、その前に、セットアップで作業しようとして時間を無駄にするかどうかを理解する必要があります。私がこれを尋ねる理由は、2 つのデータベースがあるためです。1 つはかなり「通常の」(本番データベース) で、もう 1 つはストアド プロシージャを介してこのデータベースへの制限付きアクセスを提供する「API」データベースです。 " API データベースにアクセスするユーザー アカウントと、本番データベース用の偽装アカウントの間。本番データベースのテーブルには、直接アクセスするのではなく、シノニムを介してアクセスします。トランザクションのプロビジョニングは、API データベースの「エントリ ポイント」ストアド プロシージャから行われます。
テストできるようにしたい主なことが 2 つあります。
(1) ビルド間でセキュリティ アクセスを正しく設定するのを「忘れる」と、共有オブジェクトを操作するときに問題が発生する可能性があるため、オブジェクトのセキュリティ アクセス許可。
(2) API ストアド プロシージャ/関数。一部の関数は比較的独立してテストできると思いますが、ストアド プロシージャがどのように簡単に機能するかわかりません。
- tSQLt はセキュリティ権限のテストをサポートしていますか?
- クロス データベース テストとシノニムに問題があることがわかりますが、情報はかなり歴史的なものです。これらは現在解決されていますか?
- tSQLt に CLR アクセス許可が必要なのはなぜですか?
- tSQLt「コード」は、テスト対象のデータベースにインストールする必要がありますか、それとも同じインスタンスのデータベースに対して実行できますか?
- リスト項目