ストアドプロシージャがデータベースから行を削除していることを確認するための単体テストの作成方法


8

ユニットテストは初めてですが、以下についてサポートが必要です。

ユニットテストの作成方法を学ぶための小さなプロジェクトを作成しました。アプリケーションのいずれかのフォームの機能により、ユーザーがユーザーテーブル(およびマッピングテーブルの他の行)から削除されます。

現在、これをテストするために作成した単体テストは、必要なオブジェクトを設定し、次にデータアクセスメソッドを呼び出すビジネスルールメソッド(ユーザーIDを渡す)を呼び出して、テーブルの行を削除するストアドプロシージャを実行します。

これは、何かが正常に削除されているかどうかをテストする正しい方法ですか?単体テスト/セットアップメソッドは、最初にいくつかのテストデータを挿入する必要がありますか?

回答:


8

IMHOユニットテストの学習を始めたばかりの場合は、現時点ではデータベースを省略しておくことをお勧めします。DB内のデータはテストが困難です。実際、DBを直接呼び出すコードをテストする場合、それは単体テストではなく、統合テストです。

DBを操作するコードを単体テストできますが、より高度なトピックであるJavaワールドのDBUnitなどの追加のフレームワーク、インターフェース、モックなどを含む、より多くの労力とツールが必要です。


おかげで、私の質問はおそらく非常に初心者のようです。私が難しいと思っていることの1つは、何をテストするかを決定することです!したがって、データベース内のデータのテストは、メソッドなどによって返された値をアサートするテストの記述とそれほど変わらないと思った理由
Theomax

3
そして、私が作成した小さなプロジェクトの単体テストを作成することで、多くのコードを背後にあるフォームコードではなく、ビジネスルールレイヤーに移動する必要があることに気付きました。これは、untitテストの利点の1つの例でしょうか?
Theomax

@aspdotnetuser:そうです!テスト可能なコードは保守可能なコードです。
ケビンクライン

1
when you are directly testing a DB, it isn't a unit test anymore but integration test.本気ですか?:あなたのための確かな統合が、単位はデシベルをテストすることが可能であることをアプリはデシベルでどのように機能するかしているテスト、もしblogs.msdn.com/b/atverma/archive/2010/07/28/...
StuperUser

1
@StuperUser、私の言い回しは不明瞭でした、フィードバックに感謝します:-)私が意味したことは、たとえばDBに直接依存する(およびDBを呼び出す)C#コードをテストすることでした。ユニットテスト、たとえばDB内のストアドプロシージャは、別のトピックです。上記の回答を明確にするために更新しました。
ペーテルTörök

6

SQLでSQLストアドプロシージャの単体テストを作成する方がはるかに簡単です。tSQLtを見てください。C#ユニットテストでストアドプロシージャを再テストしないでください。ラチェットフリークのアドバイスを受け、データベースをモックしてC#コードをテストします。


2

フォームのテスト中に(抽象化された)データベースをモックする必要があります

基本的に、テストを完了するために最低限必要なダミー実装を提供する

このように、フォームでsubmitを呼び出すと、データアクセスのdeleteUserが呼び出されるかどうかを確認できます

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.