2

以下のようなクラスがあるとしましょう。

それに対してユニット/統合テストをどのように書くかわかりません。リファクタリングが必要ですか？

Add / Findメソッド（実際にはそれがあります）を追加し、テストでAddを呼び出し、次にDeleteを呼び出してからFindを呼び出すだけでしょうか？

public class Repository
{
    public void DeleteProduct(int id)
    {
        var connstring = ""; //Get from web.config
        using(SqlConnection conn = new SqlConnection(connstring))
        {
            conn.Open();
            SqlCommand command = new SqlCommand("DELETE FROM PRODUCTS WHERE ID = @ID")
            command.Paramaters.Add("@ID", id)
            command.ExecuteNonQuery();
        }
    }
}
4

3 に答える 3

2

黄金律は、framewkrk のコードをテストしないことです。このメソッドにカスタム ロジックがない場合を除き、テストするものはありません。あなたが達成しようとしているのは、単体テストを簡単にするためにリポジトリを分離することだと思います。これを行う最善の方法は、リポジトリのインターフェイスを作成してモックすることです。本当にいくつかの統合テストを作成したい場合は、核爆弾の実験を行うためのテスト データベースを作成する必要があります。

于 2013-03-11T14:27:41.967 に答える
1

私の提案 - リポジトリで CRUD 以外のことを行っていない限り、(データ アクセスにフレームワークを使用しているため) リポジトリの統合テストを作成します。

Add/Find はすべて個別の Repository メソッドであり、それら自体をテストする必要があります。

シードデータをセットアップするために使用Setupして、行動できることがわかっていることをお勧めします。この場合、テーブルにレコードを挿入しProductsます。

次に行動: コールRepository.Deleteproduct(<product id created in setup>)

次のことをアサートします: セットアップで作成された製品が削除されました (データベースに再度クエリを実行して確認します)。

ORM を使用している場合、このテストは Product のマッピングもテストします。

于 2013-03-11T14:28:44.947 に答える
0

データベース呼び出しの単体テストを追加したことはありません。これは間違いなく統合テストです。あなたがチェックする観察可能なものは何もありません。

Javaには、JUnitに適合するこのためのツールがいくつかあったことを私は知っています。IT では、前後を模倣する XML ファイルを作成し、テーブルの内容を XML ファイルと比較する必要があります。.Net にも同様のものがあると確信しています。しかし、それだけの価値があるかどうかはわかりません。これらのテストは信じられないほど脆く、ほとんど価値がないことがわかりました。

実用的なアプローチを採用し、データベース オブジェクトのテストを作成しないことをお勧めします。むしろ、データベース オブジェクトと対話するオブジェクトをテストしてください。

于 2013-03-11T14:27:44.597 に答える