最近、（永続化された）計算列を含むテーブルを呼び出すプロシージャで（Red Gate SQL Testを介して）いくつかのtSQLtデータベース単体テストを作成していますが、FakeTable SPを使用すると、計算列にデータが入力されていないことがわかります（それらはnullとして評価されます）。計算された列はテストの鍵となるため、テストの列を無視することはできず、ロジックを複製したくありません。
tSQLt.AssertEqualsTable SPを使用して結果を評価しているので、両方の列の値が同じであることを確認したいと思います。
実際には、FakeTableを使用せずに、テストの最後に（部分的な）ロールバックトランザクションステートメントを使用してこれを回避しました（http://sqlity.net/en/585/how-のブログ投稿による） to-rollback-in-procedures /）またはテスト値を明示的に削除します。
このテストをコーディングするためのより良い方法があるはずだと確信しており、どんな提案も歓迎します。
テストするときは、計算列のロジックを手順のロジックから分離する必要があります。手順では、その列の情報を取得して処理します。手順では、列が計算列または実際の列であるかどうかを気にする必要はありません。つまり、テストでは、その列に配置する値をハードコーディングできます。FakeTableは、計算された列を実際の列に変換することでそれを可能にします。
別の一連のテストでは、計算列が正しく計算されていることをテストできます（テストする必要があります）。そのために、FakeTableへの追加が利用可能です。これにより、テーブルの計算されたプロパティが保持されます。EXECUTE tSQLt.FakeTableの@ComputedColumnパラメーターを1に設定する必要があります。（http://tsqlt.org/user-guide/isolating-dependencies/faketable/）
ところで、テストでは何もロールバックする必要はありません。tSQLtはすでにそれを処理しています。あなたが言及した記事で説明されているロジックは、トランザクション管理がそのプロシージャの要件である場合にのみ、独自のプロシージャで必要になります。
メーリングリストで利用可能なtSQLtのプレリリースアップデートがあります：http：//groups.google.com/group/tsqlt
プレリリースには、FakeTable中に計算列またはデフォルトを保持する機能が含まれています。
例：
EXEC tSQLt.FakeTable'dbo.tst1'、@ComputedColumns = 1;
EXEC tSQLt.FakeTable'dbo.tst1'、@ Defaults = 1;
これらはまもなく正式リリースの準備が整います。