0

初めて単体テストを見ています。私は Visual Studio 2008 を使用しているため、ビルドイン テスト フレームワークから始めました。

ボタンを押して、空欄を埋める方法を調べ始めました。すべてはかなり単純に思えます。

ただし、2 つの問題があります。

1) 空の単体テストの多くは冗長なようです。単体テストを作成しないメソッドを選択するための経験則はありますか。2) データベース (この場合は SQL Server) を読み書きするメソッドのテストを作成するためのベスト プラクティスはありますか?

(1)の例を挙げます。

WCF Web サービスの単体テストを作成しています。wscf.blue を使用して、Web サービスの WSDL/XSD を最初に記述します。

ユーザーのリストを使用してデータベースのユーザー テーブルに書き込むメソッドの (大幅に簡略化された) コードのパスを次に示します。

Entry Point
   |
   |
   V
void PutOperators(PutOperatorsRequest request) (This method is auto generated code)
   |
   |
   V
void PutOperatorsImplementation(PutOperatorsRequest input) (Creates a data context and a transaction, top level exception handling)
   |
   |
   V
void PutEntities<T>(IEnumerable<T> input) (Generic method for putting a set of entities into the database, just a for loop, T is Operator in this case)
   |
   |
   V
U PutEntity<T, U>(T entity) (Generic Method for converting the input to what the database expects and adding it to the DataContext ready for submission, T is Operator, U is the data layer entity, called User)
   |
   |
   V
(This method calls 3 methods, first 2 of which are methods belonging to "entity" passed into this method, the 3rd is an abstract method that, when overridden,  knows how to consume a BL entity and flatten it to a database row)
void EnsureIDPresent() (Ensures that incoming entity has a unique ID, or creates one)
void ValidateForInsert(AllOperators) (Does this ID already exists, etc)
User ToDataEntity(Operator entity) (simple field mapping excersice, User.Name = Operator.Name, etc)

したがって、私が知る限り、明らかにテスト可能な何かを行う3つのメソッドがあります。

EnsureIDPresent()- このメソッドは、簡単にテストできる方法でそれを入力および変更します ValidateForInsert()- このメソッドは入力を受け取り、基準が満たされない場合は例外をスローします ToDataEntity()- このメソッドは入力を受け取り、データ行エンティティを作成し、値を設定します。非常に簡単にテストできるはずです。

もあります：

PutOperatorsImplementation()- DataContext.SubmitChanges() と TransactionScope.Complete() が呼び出されるのはここです。データベースに何が書き込まれるかをテストするテストを作成する必要がありますか? そして、何？それらのレコードを削除しますか? ここで何をすべきかわからない。

次のテストを削除する必要があると思います。

PutOperators()- 自動生成されたコード、1 行で PutOperatorsImplementation() を呼び出します PutEntities()- PutEntity() を呼び出す単なる for ループであり、これは基本クラスのジェネリック メソッド PutEntity()です - 単体テストが既にある 3 つのメソッドを呼び出し、DataContext.InsertOnSubmit を呼び出します。

データを取得するための同様のパスもあります。

GetOperatorsResponse GetOperators(GetOperatorsRequest request)- 自動生成

GetOperatorsResponse GetOperatorsImplementation(GetOperatorsRequest input)- DataContext を設定する

List<Operator> GetEntities()- Linq クエリ

Operator ToOperator(User)- 1 つのデータ エンティティを同等の BL エンティティにフラット化します。

ToOperator()私はただテストするべきだと思いますGetEntities()

既知の適切なテスト データを含む専用のテスト データベースを用意する必要がありますか?

それはこれにアプローチする正しい方法ですか？

4

1 に答える 1

0

何をテストし、何をテストしてはならないかについて、「厳格な」ルールはありません。

単体テストは、作成した実装をテストし、リファクタリング時に何も壊れていないことを確信できるようにするためにあります。作成したテストが価値をもたらすかどうかを検討する必要があります。

カバーするコードを決定する際に考慮する必要がある主な事項は次のとおりです。

  • 記述しようとしている/記述したコードが変更され、リファクタリングが必要になる可能性はどのくらいありますか?
  • コードは主にカスタム コードで書かれているのか、それとも自動生成されているのか - 自動生成されている場合は、使用している自動生成器をテストするだけで適切に機能するため (そして信頼できるはずです)、テストを記述する価値はほとんどありません。

データ アクセス コードをテストするために、データベースやテスト環境外で変更できるものを使用しないでください。代わりに、「モック」を記述して、テストのデータ層からの応答をモックすることを検討してください。これにより、テストの一貫性が保証されます。Rhino Mocks や MOQ などのモック フレームワークを検討してください。

テストを書くためではなく、何らかの理由でテストを書いていることを常に覚えておいてください。作成したテストから価値が得られない場合 (たとえば、コードベースが変更されない場合) は、テストを作成しないでください。

于 2012-12-03T17:11:48.273 に答える