問題タブ [tsqlt]

RedGate と SQL テスト (tSQLt) を組み合わせて使用​​しています。単体テストを行うために、各データベースにフレームワークをインストールします。

単体テストとフレームワーク オブジェクトを 1 つの中央の場所に配置して複数のデータベースで使用できるように tSQLt フレームワークを使用する方法はありますか?

また、TFS を備えた RedGate の SQL ソース コントロールをリポジトリとして使用して、スキーマの変更を追跡しています。これらの変更は、開発 --> テスト --> 運用の環境の順序でプロモートされます。

言うまでもなく、テスト自体と組み合わされたフレームワークの追加は、現在データベース内に大量の新しい SQL オブジェクト (テーブル、ストアド プロシージャなど) を表しています。理想的には、これらのオブジェクトを開発とテストにのみ配置し、本番データベースが混乱しないようにする必要があります。tSQLt の変更を本番環境にマージすることをスキップすることもできますが、そうすると、テスト環境のソース管理に残っている変更を最後までマージ解除することになります。

この問題を回避するための考えはありますか?

tSQLt を使用して SSIS 統合テストを作成しようとしています。テーブルをセットアップしAssertEqualsTable、テストの最後にテーブルを用意しましたが、呼び出したパッケージが実行されていないようです。tSQLt テストで以下を使用しています。

SSIS パッケージの統合テストを作成しようとしています。SSIS パッケージが SSIS カタログ (SSISDB) にデプロイされました。Winders Server 2012 OS を搭載したサーバーを使用しており、SQL Server 2012 を使用しています

私のコードは以下です

私が抱えている問題は、SSMSで以下のコマンドを実行すると

SSIS パッケージはトリガーされません。

私がこれまでに試したこと：

スタックでこの投稿を読む- 私が見ることができるものから、ここで説明されているようにテストを作成しました。

SSMS で SSIS パッケージを分離して実行することになっているコードを実行します。これは期待どおりに機能します。これは、パッケージが実行され、宛先テーブルのデータが期待どおりであることを意味します。

WAITFOR DELAYコマンドの後にコマンドを追加[start_execution]して、SSIS パッケージが完了する時間があることを確認しますが、これは問題ではないようです。

tSQLt をアンインストールして再インストールします。

SQL Server データベースにロードする前に、ETL プロセスのいくつかの段階で変換および集約する必要があるさまざまなフラット ファイルを受け取ります。

各段階の後、いくつかの方法でデータを検証したいと考えており、役立つ既存の技術を調べています。

データを受信したら、切り捨てられたデータ、日付の書式設定などについて検証し、一般的にデータが変換の準備が整っていることを確認する必要があります。

このようにデータがきれいになったら、データを検証したいと思います。これは、行数、% null、平均値などの値を以前のロードまたは事前定義された値と比較することで構成されます。検証に失敗した場合は、開発者に警告する必要があります。

データベースユニットテストフレームワークであるtSQLtには、私が望むことを行うために使用できるいくつかのアサーションがあります。セットアップは簡単で、適切なドキュメントがあります。これは私が見ることができる最も近いツールですが、設計されたものとはかけ離れています。

別の方法は、独自のツールを作成することですが、知りたいのですが、このようなものは既に存在しますか?

ストアド プロシージャを呼び出すテストがあります。ストアド プロシージャは、raiserror を使用して、提供された入力を拒否することを期待しています。私の tSQLt テストの関連部分は次のとおりです。

EXEC tSQLt.ExpectException @ExpectedMessagePattern = '%複数のサブカテゴリ%';
EXEC usp_add_rfx_rfx 多くのパラメータがここに

tSQLt からのテスト結果は、usp_add_rfx_rfx sp の raiserror の重大度によって異なります。

重大度が 12 以上の場合、テストは次のメッセージで失敗します。

[test_RFX_configuration].[test_multiple_categories_and_lots] に失敗しました: (エラー) EXECUTE 後のトランザクション数は、BEGIN ステートメントと COMMIT ステートメントの数が一致していないことを示しています。前のカウント = 1、現在のカウント = 0.[16,2]{test_multiple_categories_and_lots,0} (ROLLBACK ERROR もありました --> ROLLBACK TRANSACTION 要求には対応する BEGIN TRANSACTION がありません。{Private_RunTest,149})

重大度が低い場合、テストは次のように失敗します。

[test_RFX_configuration].[test_multiple_categories_and_lots] failed: (Failure) エラーが発生することが予想されます。

私は問題をグーグルで検索し、見つけた多くのことを試しました-TRY-CATCHなどを使用しましたが、喜びはありませんでした。何か案は？

tSQLt のコード カバレッジをテストしようとしています。

「DLM Automation Suite」のサイトでSQL Coverというツールを見つけました。データベースで暗号化されているプロシージャがいくつかあるため、例外がスローされます。それはそのツールの制限ですか、それとも tSQLt テスト ケースのコード カバレッジをテストする別の方法はありますか?

Redgate SQLTest を実行したときに実行される一連のテストがあり、スクリーンショットで最初のエラーが表示されることがあります。テスト コードを手動で実行すると、実行に約 22 秒かかります。

また、以下のコマンドを使用して手動で実行すると、0 個のテストが実行され、1 秒未満で実行されます。テストが実行されない理由がわかりません。

VSTS のビルド プロセス中に SQL 単体テストを実行することはできますか (理想的には、テストが失敗するとビルドが失敗します)。または、ドロップ サーバーの SQL Server でビルド/展開した後にのみテストを実行できますか?

ありがとう！

実稼働コードで SQL Server の tSQLt 単体テストを使用し始めています。現在、私はErland Sommarskog のSQL Server のエラー処理パターンを使用しています。

Erland Sommarskog は、常にXACT_ABORT を ON に設定することを推奨しています。これは、SQL Server が (ほぼ) 一貫した方法でエラーを処理するためです。

ただし、これは tSQLt を使用する場合に問題を引き起こします。tSQLt は、明示的なトランザクション内ですべてのテストを実行します。テストが完了すると、トランザクション全体がロールバックされます。これにより、テスト アーティファクトのクリーンアップが完全に簡単になります。ただし、XACT_ABORT を ON にすると、TRY ブロック内でエラーがスローされると、そのトランザクションはすぐに破滅します。トランザクションは完全にロールバックする必要があります。コミットすることも、セーブ ポイントにロールバックすることもできません。実際、トランザクションがロールバックされるまで、そのセッション内のトランザクション ログには何も書き込むことができません。ただし、テストの終了時にトランザクションが開いていない限り、tSQLt はテスト結果を適切に追跡できません。tSQLt は実行を停止し、運命の ROLLBACK ERROR をスローしますトランザクション。失敗したテストは (成功または失敗ではなく) エラーのステータスを示し、後続のテストは実行されません。

tSQLt の作成者である Sebastian Meine は、別のエラー処理パターンを推奨しています。

エラー変数を宣言し、トランザクションを開始し、セーブ ポイントを設定してから、TRY ブロック内でプロシージャ コードを実行します。TRY ブロックがエラーをスローした場合、実行は CATCH ブロックに渡され、エラー変数が設定されます。次に、TRY CATCH ブロックから実行が渡されます。エラーが発生すると、トランザクションは手順の最初に設定されたセーブ ポイントにロールバックします。その後、トランザクションがコミットされます。SQL Server が入れ子になったトランザクションを処理する方法により、この COMMIT は、別のトランザクション内で実行されると、トランザクション カウンターから 1 を減算するだけです。(ネストされたトランザクションは実際には SQL Server には存在しません。)

Sebastian は非常にきちんとしたパターンを作成しました。実行チェーン内の各プロシージャは、独自のトランザクションをクリーンアップします。残念ながら、このパターンには大きな問題があります: 破滅的なトランザクションです。失敗したトランザクションは、セーブ ポイントまたはコミットにロールバックできないため、このパターンを破ります。完全にロールバックすることしかできません。もちろん、これは、TRY-CATCH ブロックを使用するときに XACT_ABORT ON を設定できないことを意味します (常に TRY-CATCH ブロックを使用する必要があります)。 . さらに、セーブ ポイントは分散トランザクションでは機能しません。

どうすればこれを回避できますか? tSQLt テスト フレームワーク内で動作し、運用環境で一貫した正しいエラー処理を提供するエラー処理パターンが必要です。実行時に環境をチェックし、それに応じて動作を調整することができました。(以下の例を参照してください。)しかし、私はそれが好きではありません。私にはハックのように感じます。開発環境を一貫して構成する必要があります。さらに悪いことに、実際の製品コードをテストしていません。誰もが素晴らしい解決策を持っていますか?

編集:さらにテストした後、変更したロールバックも機能しないことがわかりました。プロシージャがエラーをスローすると、ロールバックもコミットもせずに終了します。プロシージャが終了するときの @@TRANCOUNT がプロシージャが開始するときのカウントと一致しないため、tSQLt はエラーをスローします。いくつかの試行錯誤の後、テストで機能する回避策を見つけました。2 つのエラー処理アプローチを組み合わせて、エラー処理をより複雑にし、一部のコード パスをテストできません。より良い解決策を見つけたいと思います。