ユニットテストについて質問があります。現在、私は多くのSPを呼び出し、ほとんどのメソッドのリターンを取得しない大規模なプロジェクトを持っています。実際、これは多くのSQL呼び出しの大きなラッパーです。すべてSPに保持されているため、多くのロジックはありません。また、インラインSQLのセクションもあります。
このc＃プロジェクトを単体テストする必要がありますが、すべてが嘲笑される多くのSPを呼び出すため、単体テストは無意味であることが明らかになりつつあります。私はこれについて間違って考えているのではないかと心配しています。
私の質問は、誰かがこの問題を抱えていて、彼らは何をしたのかということです。代わりにデータベースの単体テストを行う場合は、洞察があれば非常に役立ちます。
ありがとう。
単体テストは、統合テスト/システム テストになるため、データ アクセス レイヤーに触れてはなりません。テストできることは、プロジェクトが実際にデータ アクセス レイヤーを呼び出すことです。これを行うと、リファクタリング中にボタンをクリックすると常にデータ アクセス レイヤーが呼び出されるという安心感が得られます。
//Arrange
var dataAccessMock = new Mock<IDataAccessMock>();
dataAccessMock(da => da.ExecuteSomething());
IYourApplication app = new YourApplication(dataAccessMock);
//Act
app.SomeProcessThatCallsExecuteSomething("1234567890");
/Assert
dataAccessMock.Verify(dp=>da.ExecuteSomething(), Times.Once());
注、この例ではMoqを使用しています
これが好みに合わせてテストされたら、統合テストに集中して、ストアド プロシージャが意図したとおりに機能することを確認できます。このためには、既知の状態でデータベースをアタッチし、ストアド プロシージャを実行してから、データベースを元に戻すか破棄して、テストを繰り返し実行できるようにするために、かなりの作業が必要になる可能性があります。
テスト戦略を統合テストと単体テストに分割する必要があります。
統合テストでは、既存のデータベースを利用できます。通常は、ここでより高度なテストを作成し、アプリケーションがデータベースと正しく対話することを確認します。
単体テストでは、モックアウトするのに実際に意味のある選択されたシナリオのみを選択する必要があります。これらは通常、多くのビジネス ロジックがデータベース ロジックの "最上位" にあり、そのビジネス ロジックを検証する必要があるシナリオです。時間の経過とともに、より多くのデータベース コールを模擬できますが、最初は重要な場所を特定します。
一般的に、ビジネス ロジックをデータ アクセス レイヤーではなくビジネス レイヤーに配置する必要がある理由の 1 つを発見しました。確かに、パフォーマンスや場合によってはセキュリティ上の問題によって決定される例外はありますが、例外のままにしておく必要があります。
そうは言っても、sproc をテストするための戦略を策定することはできます (ただし、sproc の範囲によっては、それらのテストを「単体テスト」と呼ぶのが正しい場合とそうでない場合があります)。
どちらの方法でも単体テスト フレームワークを使用できます。
初期化セクションで、データベースのテスト コピーを既知の状態に復元します。たとえば、以前に保存したコピーからロードします。
次に、ストアド プロシージャを実行する単体テストを実行します。通常、ストアド プロシージャは何も返さないため、単体テスト コードはデータベースから値を選択して、予期した変更が行われたかどうかを確認する必要があります。
ストアド プロシージャ間の相互作用の可能性によっては、各テスト間、または関連するテストのグループ間でデータベースを復元する必要がある場合があります。
データ/永続層は、単体テストの観点から最も無視されることが多いコードです (テストの二重を使用した真の単体テスト: モック、スタブ、フェイクなど)。データベースに接続している場合は、統合テストを行っています。私は、a) よく設計されたデータ/永続層が副作用としてテストしやすい (インターフェイス、優れたデータ アクセス フレームワークの抽象化などを使用する)、および b) 実際にユニットおよび統合テスト済みのプロパティであることに価値を見出します。