0

私はnunit、moqを使用しており、TDDを実行しようとしています。

いくつかのユーザーアカウントを返すクエリがあります。条件のコレクションを取得する別のクエリがあります。

各アカウントを調べて、各アカウントをコレクションと照合し、ユーザーアカウントがどのような条件に該当するか（ある場合）を確認します。

public void Test()
{
  var accounts = GetAccounts();
  var conditions = GetConditions();

  foreach(var a in accounts)
 {
    var found = conditions.Where(x => x.condition1 >= a.condition1 && x.condition2 <= a.condition2).FirstOrDefault();

    if(found)
    {
      // move on to next condition in flow chart
    }
    else
    {
       continue;
    }
 }

}

これをTDDでテストするにはどうすればよいですか。正しい条件が見つかったかどうかを確認したいですか？これを公的な方法にするのが賢明だとは思いませんし、誰かが条件をチェックするという私のアプリケーションには何の意味もありません。

したがって、この条件が後で数値を計算するために使用されるため、実際に何をテストするかがわかりません。これは、適切な条件が呼び出されたかどうかを確認するために使用できます。それは基本的にメソッドの終わりを意味し、数は他の何かの影響を受けた可能性があり、TDDを理解する方法を打ち負かすでしょう（メソッドを一度に1つずつ記述しますが、最初に単体テストを行います）試して）

編集

はい、それが私が始めたことです。モックと偽物を作りました。すべてをセットアップしましたが、結果を検証するために使用するものに固執しました。私が作成している方法は、おそらく無効のままになります（エラーをログに記録するか、ある時点で顧客アカウントを更新します）。アプリケーションはスケジュールされたタスク（コンソールアプリ）として実行されるため、これは実際にはアプリケーション内の唯一のパブリックメソッドであり、基本的には「実行」メソッドです。すべてのビジネスケースを含むビジネスレイヤーに多くのプライベートメソッドがあります。最終的に、ユーザーはスキップされるか、条件を満たしている場合はペナルティが科せられます。ペナルティは彼らのアカウントに更新されます。

はい、条件メソッドをパブリックまたは内部にすることはできますが、ビジネスレイヤーの外部のメソッドがそれらについて知っている必要があるとは思いません。それはそのビジネスレイヤーにのみ関連しており、その「実行」メソッドが実行されたときにのみその上に配置されます。

これが、TDDを私にとって非常に難しいものにしている理由です。彼らは、私がユーザーと対話し、ユーザーに何らかのフィードバック（つまり成功メッセージ/結果）を送信する可能性が最も高いWebサイトを作成している場合は、パブリックメソッドのみをテストすると言います。しかし、1つのパブリックメソッドを介して実行されるスケジュールされたタスクとして実行する必要があり、残りは単なるビジネスルールであるアプリケーションを入手した場合、それをテストする方法を理解するのは非常に困難です。

SUT内部とは何ですか？

4

2 に答える 2

0

他のテストと同様に、いくつかの偽の依存関係（この場合はユーザーと条件）を指定し、テストしている関数の出力を事前定義された期待される結果と比較する必要があります（この場合、私が正しく理解していれば、各アカウントに期待される状態があることを確認したい）。

偽のユーザーリストと偽のルールリストをSUT（テスト対象システム）に挿入するテストを作成し、ユーザーの実際のリストとその状態を予想されるリストと比較できます。

テストは次のようになります。

[Test]
public void Rules_matcher_with_premium_users_should_have_free_access()
{
    var customer = Mock<IAccount>>);
    var condition = Mock<ICondition>();
    customer.Setup(c => ...); // set up condition
    condition.Setup(co => ...); // set up condition
    var sut = new MyBusinessLogic(customer.object, condition.object);
    var result = sut.DoConditionCheck();

    Assert.AreEqual(condition.object.Id, customer.object.Condition.Id);
}

私がここで行ったことは、あなたが言ったように、顧客が正しい状態にあるべきであると述べるテストの例です。条件と顧客にスタブを使用し、ルールエンジンが機能することを前提として、顧客はその条件を持っている必要があります。

カプセル化について：ほとんどのTDD純粋主義者によると、テストするのはパブリックAPIのみです。それ以外のものは、テストするパブリックAPIによって呼び出されることの副作用としてテストされます。公開されていない場合は、実装の詳細であり、直接テストする必要はありません。テストが必要な場合は、公開してください。

もう少しリラックスした眺めをします。SUTを内部にし、属性を使用して単体テスト用に公開しInternalsVisibleTo、テストアセンブリを指定できます。

于 2012-10-23T13:02:59.690 に答える
0

あなたはあなたの発言の中でフローチャートに言及しています。だから、フローチャートオブジェクトを作成してそれに対してテストしてみませんか。アカウントを受け取るGetNextStepのようなメソッドがあり、返されたステップが期待するステップであることがわかります。

于 2012-10-23T06:29:58.420 に答える