1

まったく同じスキーマで、実際のテーブルと期待されるテーブルが 2 つ定義されています。予想されるテーブルに、ID が 2、1 の 2 つの行を挿入します。

走る

INSERT INTO actual EXEC tSQLt.ResultSetFilter 1, '{statement}'

次に実際のデータを入力します

EXEC tSQLt.AssertEqualsTable @expected = 'expected' , @actual = 'actual'

結果を比較します。

データの順序が異なっていても (実際の ID は 1、2)、テストはパスします。

テストで SELECT * FROM actual と SELECT * FROM expected を追加し、tSQLt.Run '{テスト名}' でテストを独自に実行して、データが異なることを確認しました。

これが既知のバグかどうかは誰にもわかりませんか? どうやら行ごとにチェックすることになっているので、順序をチェックする必要があります。返される他のすべての列は NULL であり、値を含むのは ID 列だけです。

4

1 に答える 1

3

selectステートメントでorderby句が指定されていない限り、順序はSQLサーバーによって保証されません（このMSDNページの一番上の箇条書きを参照してください）。ただし、実際には、予想どおりに順序付けられることがよくあります。

このため、tSQLtが同一ではない同一の行を探すことは理にかなっていると思いますが、順序を確認することは理にかなっています。そうしないと、SQLサーバーの気まぐれで答えが変わる可能性があり、テストは無意味になります（さらに悪いことに、断続的に失敗します） ！）。AssertEqualsTableのtSQLtユーザーガイドには、テーブルの内容はチェックされますが、テーブル内の順序はチェックされないと記載されています。注文もチェックする必要があると結論付ける理由は何ですか？私はそれについての言及を見つけることができませんでした。

順序を確認する必要がある場合は、期待される結果と実際の結果の両方をID列のある一時テーブルに挿入して（またはROW_NUMBERを使用して）、結果のテーブルを確認できます。順序が異なると、ID列も異なります。

GregMLucasのブログに同様の方法が記載されています。

order by句なしでテーブルから返された順序に依存することはお勧めしません（MSDNリンク）-したがって、アプリケーションのステートメントの呼び出しに1つ含めるか、返される行の順序が重要な場合はその中にSPを含めることをお勧めします。

于 2012-10-18T07:00:07.323 に答える