5

ここで同様の質問を見て、人々の回答がどこに向かっているのかの要点を理解していると思いますが、ソリューションのスタブリポジトリを使用して純粋な単体テストを作成する必要があるかどうかを確認する必要があります。

次の単体テスト (Microsoft の Fake Assemblies と MSTest を使用して作成) がある場合:

 [TestMethod]
 public void creating_user_returns_a_valid_id()
 {
     var userId = new Random().Next(1, 1000);

     var userRepository = new StubIDataEntityRepository<User>
     {
         CreateT0 = x =>
             {
                 return userId;
             }
     };

     var user = new User();

     var result = userRepository.CreateT0(user);

     Assert.AreEqual(result, userId);
 }

現在、私は単体テストについて勉強しており、純粋な単体テストは境界や責任を超えてはならないことを理解しています。したがって、スタブです。データベースでのユーザーの作成が実際に有効なユーザー ID になることをテストしたい場合は、統合テストを作成する必要があることを理解しています。では、正確には、ここで何をテストしているのでしょうか? 私は人々がアプリケーションロジックを言うことを知っていますが、それはすべて非常に有効ですが、確かに私はIDを作成し、偽のリポジトリにCreateメソッドからそのIDを返すように指示し、Createメソッドから返されたIDが同じ値であることを確認するテストを作成しています. 本質的に次のことのために多くの作業を行っているように感じます。

x = 1, y = 1, assert.areequal(x,y)!!

その答えは、開発者が TDD を介してコードを設計できるようにトレーニングすることでしょうか? そこにいる TDD の達人が私を啓発してくれるなら、それは大歓迎です!

敬具

ベン

4

3 に答える 3

10

ここでは、有用なものをテストしていません。

すべての単体テストには、いわゆるSystem Under Test (SUT) があります。それがテストしたいクラスです。
SUT をテストするには、SUT ではなくモックをテストするため、それをモックしてはなりません。そして、それはちょっと無意味です。

あなたの場合、リポジトリをテストしたいように見えますが、リポジトリをモックしているため、テストが無意味になります。

SUT がリポジトリを使用する別のクラスであるテストでモック リポジトリを使用したい。

リポジトリのテストは、統合テストのタスクである可能性が最も高いです。データベースに直接アクセスするリポジトリ メソッドは、単体テストではテストできません。

于 2013-01-07T15:53:43.840 に答える
3

データ アクセスを「モック」または「スタブ化」することで、単体テストがコードのパフォーマンスのみを評価していることを確認できます。モックを使用すると、呼び出されたときにどのデータが返されるか、どのような形式を取るべきかを正確に知ることができます。データベースやデータファイルに書き込みを行っているのはあなただけではない可能性があるため、テスト結果が微妙に異なり、頭を悩ませている可能性があります。

プロセス業界では、この概念は分離テストと呼ばれ、単体テストで何を達成しようとしているのかをよりよく理解できます (IMHO)。「たくさんの仕事をする」というあなたの言うことは、プロジェクトを始めたばかりのときは有効ですが、プロジェクトの複雑さは一種のエントロピーです。早い段階で適切なプラクティスを実践することで、後でデバッグの悪夢を回避できる可能性があります。

それが役立つことを願っています:)

于 2013-01-07T15:53:07.770 に答える
0

質問は非常にうまく作成されています..そして私の答えは、あなたの鼻が何か疑わしいにおいがする場合、それはおそらくそうです.

DB とのインターフェイスをアプリ化する場合は、DB アクセスをロール (通常は XXXRepository と呼ばれます) に委任する必要があります。ここで、XXX は永続化されるリソースのタイプ (顧客など) です。

  • XXXRepository の実装をテストする場合は、統合テスト (つまり、アプリの残りの部分が DB サブシステムと統合されていることを確認するテスト) を作成する必要があります。つまり、契約（XXXRepository）の条件は満たされていますか。したがって、「契約テスト」という名前が付けられました。
  • 「アプリの残りの部分」セクションでコードをテストする場合は、単体テストを作成し、分離と速度の理由から XXXRepository ロールをモックアウトする必要があります。

簡単に言えば、SUT がファイルへの書き込みを担当している場合、テストでは SUT メソッドを呼び出し、それに応じてファイルが変更されたことを確認する必要があります。それ以外は..あとで驚きの準備をしているところです。

于 2013-01-08T06:30:48.340 に答える