在TDD中重新设计后该方法变为私有后，方法的测试会如何？

假设我开始开发角色扮演游戏，角色扮演者会攻击其他角色以及类似的东西。

应用TDD，我做了一些测试用例来测试Character.receiveAttack(Int)方法内部的逻辑。像这样：

@Test
fun healthIsReducedWhenCharacterIsAttacked() {
    val c = Character(100) //arg is the health
    c.receiveAttack(50) //arg is the suffered attack damage
    assertThat(c.health, is(50));
}

说我有10种方法测试receiveAttack方法。现在，我添加一个方法Character.attack(Character)（调用receiveAttackmethod），并在经过一些TDD循环测试之后，我做出一个决定：Character.receiveAttack(Int)应该是private。

前10个测试用例会发生什么？我应该删除它们吗？我应该保留方法public（我不这样认为）吗？

这个问题不是关于如何测试私有方法的，而是关于在应用TDD时重新设计后如何处理它们的问题。

在TDD中，测试充当设计的可执行文档。您的设计已更改，因此很显然，您的文档也必须更改！

请注意，在TDD中，该attack方法可能出现的唯一方法是测试通过失败的结果。这意味着，attack正在通过其他测试进行测试。这意味着的测试间接 receiveAttack覆盖了该attack测试。理想情况下，对的任何更改receiveAttack都应至少破坏的一项attack测试。

如果没有，那么其中的功能receiveAttack就不再需要，也不应该再存在！

因此，由于receiveAttack已经通过进行了测试attack，因此您是否保留测试也没关系。如果您的测试框架使测试私有方法变得容易，并且如果决定测试私有方法，则可以保留它们。但是您也可以删除它们，而不会失去测试的覆盖范围和信心。

如果该方法足够复杂以至于需要测试，则应在某个类中公开。因此，您可以根据以下内容进行重构：

public class X {
  private int complexity(...) {
    ...
  }
  public void somethingElse() {
    int c = complexity(...);
  }
}

至：

public class Complexity {
  public int calculate(...) {
    ...
  }
}

public class X {
  private Complexity complexity;
  public X(Complexity complexity) { // dependency injection happiness
    this.complexity = complexity;
  }

  public void something() {
    int c = complexity.calculate(...);
  }
}

将X.complexity的当前测试移到ComplexityTest。然后通过模拟复杂性向X.something发送文本。

以我的经验，重构为较小的类和较短的方法会带来巨大的好处。它们更易于理解，更易于测试，并且最终被重用，超出了人们的预期。

说我有10种测试receiveAttack方法的方法。现在，我添加了一个Character.attack（Character）方法（调用receiveAttack方法），经过一些TDD循环测试之后，我做出一个决定：Character.receiveAttack（Int）应该是私有的。

这里要记住的一点是，您所做的决定是从API中删除方法。向后兼容的礼貌暗示

1. 如果您不需要删除它，则将其保留在API中
2. 如果你不需要删除它尚未，然后将其标记为过时，如果可能的话文档时的生活到底会发生
3. 如果确实需要删除它，那么您将有一个主要版本更改

当您的API不再支持该方法时，将删除/或替换测试。那时，私有方法是一个实现细节，您应该可以重构它。

到那时，您回到了标准问题，即您的测试套件是否应直接访问实现，而不是纯粹通过公共API进行交互。私有方法是我们应该能够替换的，而不会妨碍测试套件。因此，我希望与之相伴的测试会消失—要么退休，要么将实现与单独的可测试组件一起使用。