1

私は2つのテストを行っていますが、それらはまったく同じです... 2つのことを除けば、2つの別々のサービスコールを呼び出します。したがって、mockitoを使用する場合、2つの別々の期待値と検証ラインがあります...

これは私がしたことです：

@test
TestA {
   baseTest("player");
}

@test
TestB {
  baseTest("member");

}

BaseTest(type type) {
  ....
  .....
  if type(player) {
    Mockito.when(player service call)
  }
  else {
    Mockito.when(member service call)
  }

  // make the call in code

  //verify

  if(player) {
     verify player specific service call...
  }
  else {

  }
}

上記はテスト臭だと思います...ちょうど気分が悪いです...

私のbasteテストにIfステートメントを配置するよりも良い方法はありますか？

4

4 に答える 4

4

そのようなステートメントが繰り返されるのを目にするところならどこでも、ポリモーフィズムを使用できます。「playerservicecall」メソッドと「memberservicecall」メソッドは、既存のBaseTestメソッドも所有するスーパークラスBaseTestSuperで抽象化する必要があります。

于 2012-09-20T12:45:04.733 に答える
3

テストコードを独立して開発し、意味のあるものに参加する必要があります。

例によって。初期化コード（Arrange / Act / Assertの最初のA）の経験則は次のとおりです。

  1. テストでは、テストメソッドのすべてのアレンジ部分を記述する必要があります。
  2. メソッドが他のすべてのメソッドと初期化を共有している場合は、@Setupメソッドに入れます
  3. 一部のテストメソッドがその初期化を共有しない場合、それはおそらくそのテストケースに適合しないためです。

だから私の結論は：

  1. 独立したテストを書く
  2. 彼らが物事を共有する場合、あなたはリファクタリングすることができます
  3. しかし、あまり多くはありません（または「if」のような奇妙なことで）!!! 再利用ではなく、複雑さを追加します。

実際、@ artbristolの答えは理にかなっています。代替動作にifを使用している場合は、ポリモーフィズムを検討してください。どの時点までテストが複雑かどうかはわかりません（コードが同様のクラス階層をテストしている場合はおそらく意味があります）。

于 2012-09-20T12:48:30.907 に答える
0

それでも、2つのテストクラスを別々に実装します。コードの長さと重複はテストでは実際には重要ではなく、コードの可読性、徹底性、正確性が優先されます。その観点から、2つのテストケースを別々に実装するだけです。

于 2012-09-20T12:43:11.590 に答える
0

一般に、テストに複雑さを加えるべきではありません。まず、そこで間違いを犯す可能性があります（単純なifでも）。第二に、あなたのテストはもはやドキュメントではありません。つまり、テストされたクラスの使用と動作のシナリオが何であるかを簡単に理解することはできません。

だから匂いです。:)

于 2012-09-20T19:05:22.473 に答える