3

私はtSQLtデータベースユニットテストフレームワークにまったく慣れていません。3 つのテーブルを使用するストアド プロシージャがあります。各テーブルには 15 行のデータが必要です。結果を検証するために、別の偽のテーブルも必要です。しかし、偽のテーブルを準備するために INSERT を使用するのはエラーが発生しやすく、保守が困難です。

tSQLt faketable 用にデータを準備するためのベスト プラクティスは何ですか?

ありがとう。

4

1 に答える 1

7

これは、コードサンプルなしで思いつくことができる最良の答えです:

FakeTable のアイデアは、テスト中にテスト データをテーブルに簡単に挿入できるようにすることです。制約を含まないコピーでテーブルを置き換えます。これは、テストしようとしているストアド プロシージャ、関数、ビューなどで使用されるテーブルにのみデータを配置できるようにするためです。

その時点まで、FakeTable は制約を取り除いたので、関心のあるテーブルの列にのみデータを自由に挿入することもできます。つまり、insert ステートメントを短くすることができます。

各テーブルには 15 行のデータが必要だとおっしゃいました。単体テストを書いているとき、コードの特定のビットをテストするために非常に多くのデータが必要になることはめったにありません。たとえば、非常に複雑な select ステートメントを含むストアド プロシージャをテストする場合、その select ステートメント内で発生する可能性のあるさまざまな条件に対して複数のテストを記述します。これにより、テストが失敗したときに、問題が発生したコードの場所をより簡単に特定できます。

また、結果を検証するには偽のテーブルが必要だと言います。テストしている結果をテーブルに挿入するか、期待値を保持するテーブルを作成する必要があることを意味していると思います。(ここでも、例を投稿すると非常に役立ちます)。これは、ビューの結果をキャプチャして、期待される結果と実際の結果を比較する方法の例です。Actual または Expected テーブルには FakeTable を使用していないことに注意してください。

CREATE PROCEDURE MyTests.[test CustomerOrderSummary counts orders for each customer]
AS
BEGIN
  EXEC tSQLt.FakeTable 'Demo.Order';

  INSERT INTO Demo.Order (OrderId, CustId) VALUES (1, 12);
  INSERT INTO Demo.Order (OrderId, CustId) VALUES (2, 12);
  INSERT INTO Demo.Order (OrderId, CustId) VALUES (3, 12);
  INSERT INTO Demo.Order (OrderId, CustId) VALUES (4, 55);
  INSERT INTO Demo.Order (OrderId, CustId) VALUES (5, 55);

  SELECT CustId, NumOrders
    INTO MyTests.Actual
    FROM Reports.CustomerOrderSummary;

  SELECT TOP(0) *
    INTO MyTests.Expected
    FROM MyTests.Actual;

  INSERT INTO MyTests.Expected (CustId, NumOrders) 
      VALUES (12, 3);
  INSERT INTO MyTests.Expected (CustId, NumOrders) 
      VALUES (55, 2);

  EXEC tSQLt.AssertEqualsTable 'MyTests.Expected', 
                               'MyTests.Actual';
END;
于 2015-03-09T13:14:47.350 に答える