设计和测试此类的正确方法答案

【问题标题】：Correct way to design and test this class设计和测试此类的正确方法
【发布时间】：2013-10-10 05:45:00
【问题描述】：

我正在开发解释器，并希望对解释模型的“执行”方法进行内部测试。 execute 方法没有输入或输出，因此测试该方法的唯一方法（至少据我所知）是模拟内部方法调用以查看它们是否以正确的顺序执行。

目前我有以下课程：

ExecutableInstance - 可以执行的模型类。
ExecutableInstanceFactory - 创建可执行实例的单例类（实现为枚举），根据给定的参数使用不同的方法。
ModelAnalyzer - 包含分析模型的方法的单例类

解释器调用ExecutableInstance类的execute()方法，然后调用ModelAnalyzer来理解模型中的内部可执行实例。然后它使用ExecutableInstanceFactory 创建新的ExecutableInstances，然后根据模型的定义方式调用它们的execute() 方法。

我的想法是模拟ExecutableInstanceFactory 类，以便它返回模拟ExecutableInstaces，然后我可以测试执行顺序。但这意味着我必须将ExecutableInstanceFactory 注入ExecutableInstance。由于它是单例，因此将其作为参数传递将是愚蠢和愚蠢的。我曾想过使用 Google 的 Guice 进行 DI ......但我一直在尝试这样做。

我的方向正确吗？如果有，应该如何实现？

【问题讨论】：

标签： java unit-testing mocking tdd

【解决方案1】：

我会用这个执行方法制作一些更小的方法。例如 - 一种解析方法将某些内容返回给执行方法，然后另一种方法对返回的数据执行某些操作并返回其他数据等。然后您不必测试 Execute 方法，只需测试较小的方法。这也可以让您更轻松地检测错误。

【讨论】：

考虑过了，但这会破坏ExecutableInstance 类的封装。今天这样认为可以吗？
只要方法有意义，我认为封装不会破坏，因为每个方法都可以在另一种情况下使用 - 例如，如果您只想解析代码而不执行它。

【解决方案2】：

执行方法没有输入或输出

因此，应该在班级的合作者身上验证行为（使用模拟）。

既然是单例，把它作为参数传递就很愚蠢。

您在测试中遇到问题的事实表明您的设计存在缺陷。摆脱单例并注入协作者。

【讨论】：