平衡设计原则：单元测试

Question

我正在编写 Bananagrams 的模拟。目前，我有一个 GameMaster 类来维护公共的棋子集合。 deal(Player) 方法向该玩家发一定数量的棋子。

我想为此编写单元测试。然而，此时我没有吸气剂，因此无法检查对象的状态。

为什么不添加吸气剂？我不想仅将代码添加到公共接口以进行测试。目前，没有其他理由公开这些功能。

我应该在这里做什么？无论如何添加吸气剂，使公共 API 变得混乱（或者希望将来需要它们）？放弃单元测试？ （听起来是个坏主意。）

或者，这是否表明我的公共界面有缺陷？

Answer 1

不要依赖于 Player 的具体实例，而是将单元测试编写到接口（或等效项），并依赖模拟或其他交互来验证玩家是否处于正确的状态，而只是验证正确的调用（从 GameMaster 类的角度来看，

如果您无法在不验证 Player 的最终状态的情况下验证 GameMaster 类的正确行为，则表明您的职责不正确。发生了什么，而玩家应该负责采取适当的操作，

这也是一个好处，因为这意味着对 GameMaster 的测试将仅依赖于 GameMaster 类的行为，并且不需要。如果 Player 类更改其行为，

请避免为单元测试添加 getter。当您想添加 getter 时，请考虑使用交互测试（正如我刚才所描述的）而不是基于状态的测试。

Answer 2

验证一段代码是否有效的方法不止一种。我们大多数人首先想到的是基于状态的测试（即使用 getter 来验证对象的最终状态是否是您认为应该的状态）。但是，验证代码是否有效的另一种方法是使用基于行为或交互的测试。

Martin Fowler 在这里写了一篇关于差异的不错的文章

Answer 3

您应该测试内部使用这些状态保存变量的功能。如果没有公共功能使用它们，那么它们就是死代码。

Answer 4

我想说的是，你的课程可能做得太多了。听起来你让它们存储状态并做其他事情。

考虑什么可以让它们更容易测试。如果将状态和逻辑分开，您将如何测试它们？ 而不仅仅是调用

GameMaster gameMaster = new GameMaster;
playerOne.Score = gameMaster.ComputePlayerScore(newScore);

您可以将 GameState 的纯状态实例传递到 GameMaster 例程的构造函数中，

GameState gameState = new GameState;    
GameMaster gameMaster = new GameMaster(gameState);
playerOne.Score = gameMaster.ComputePlayerScore(newScore);

：然后您的单元测试例程可以传入 gameState 和 newScore 所需的任何数据，并在 gameState 返回后检查 gameState 中的结果。依赖注入是你的朋友。

Answer 5

您可以做的一件事是对主类进行子类化以提供用于测试的吸气剂。如果您有可以使用的接口，这会更容易。

子类化以提供吸气剂是一个半危险的提议。如果您只是为内部属性提供吸气剂，那么损害将是最小的，但您需要小心，您正在测试实际类，而不是您的派生版本。

Answer 6

我认为专门为可测试性添加代码没有什么问题。单元测试对于回归测试来说是无价的。

但是，它不应该影响您的公共 API，这也是正确的。因此，我建议对 getter 进行包保护，并将单元测试放在与 Player 类相同的包中。 （不过，在不同的源文件夹中，这样您就可以将生产代码和测试代码完全分开。）

Answer 7

单元测试不会使您的代码变得更好，它们会使您的整个应用程序随着时间的推移通过更改和添加功能变得更加稳定。这就是为什么如果您的 GameMaster 类中没有公共 getter，则无需为单元测试创​​建它们。

没有吸气剂并不意味着你的界面是流畅的，测试驱动开发的概念是编写最少的代码来通过测试（来自需求），如果你不需要它们，你就不会编写它们。在单元测试消失很久之后，打印、跟踪、日志将在这里（好吧，它们也将留在这里，但在许多情况下被过度使用和过度使用）

Answer 8

我在这里应该做什么？无论如何添加吸气剂，使公共 API 变得混乱（或者希望将来需要它们）？

我没有得到这个回应。 getter 如何变得“混乱”？

您正在进行测试驱动开发。该设计是由测试一切的绝对需要驱动的。

Getter 并不“混乱”。它们是你测试事物的方式。

“放弃单元测试？”

我认为这不是一个好主意。