1

我有两个测试，它们完全相同...除了两件事，它们调用两个单独的服务调用..因此，当我使用 mockito 时，我有两个单独的期望和验证行...

这就是我所做的：

@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

任何你看到重复的 if 语句的地方，你都可以使用多态性。您应该在超类 BaseTestSuper 中抽象“玩家服务调用”和“成员服务调用”方法，它也将拥有现有的 BaseTest 方法。

于 2012-09-20T12:45:04.733 回答
3

你应该独立开发你的测试代码，并在它们有意义时加入它们。

举个例子。初始化代码（Arrange/Act/Assert 的第一个 A）的一个经验法则是：

  1. 您应该在测试中编写测试方法的所有 Arrange 部分。
  2. 如果您的方法与所有其他方法共享初始化，则将其放入 @Setup 方法中
  3. 如果某些测试方法不共享该初始化，则可能是因为它不适合该测试用例。

所以我的结论是：

  1. 编写独立测试
  2. 如果他们分享你可以重构的东西
  3. 但不要太多（或者像“如果”这样奇怪的事情）！！！增加了复杂性，而不是重用。

事实上@artbristol 的回答是有道理的：如果你使用 if 的替代行为考虑多态性。只是我不确定直到哪一点测试是否复杂（如果代码正在测试类似的类层次结构，这可能是有意义的）。

于 2012-09-20T12:48:30.907 回答
0

一般来说，你不应该给你的测试增加任何复杂性。首先，您可能会在那里犯错（即使在简单的 if 中）。其次，您的测试不再是文档，这意味着您无法轻易理解测试类的使用场景和行为。

所以它是一种气味。:)

于 2012-09-20T19:05:22.473 回答
0

我仍然会分别实现 2 个测试类。代码长度和重复对于测试来说并不重要，代码可读性、完整性和正确性是优先考虑的。鉴于此，只需分别实现 2 个测试用例。

于 2012-09-20T12:43:11.590 回答