Java 在单元测试中将应用程序类用作实用程序

这是一个关于单元测试最佳实践的问题。假设我有一个

ClassA

，它执行一些对象转换（从csv到javabean，使用外部库）。然后我有了

ClassB

，它需要这些经过转换的javabean来执行计算。 在为

ClassB

编写单元测试时，是否可以使用

ClassA

的转换方法来获取这些转换后的bean对象？换句话说，在单元测试中使用应用程序类作为实用工具

---

另一个选项是编写一个util测试方法，该方法的代码与

ClassA

相同（转换是使用外部库完成的，因此在应用程序类和测试实用程序类中都很容易使用它）

当您对一个方法进行单元测试时

• 准备数据（模拟、硬编码等）
• 您调用被测试的方法
• 你评估结果

你不做的是调用其他东西，实用方法等

为什么?

因为这意味着您的代码依赖于其他东西，并且它不会孤立地运行

---

这也意味着你的测试有太多关于代码的知识，这是一件坏事，尤其是当你开始重构的时候。对代码了解太多意味着，一旦更改代码，就会破坏大多数测试，而这些测试的目的之一就是简化重构（和开发人员的生活）。

您询问的是最佳实践，因此我不会回答您的特定示例（其他人已经为您提供了一些如何处理它的提示），但我将研究一般性问题：在测试代码中使用应用程序类作为实用程序类是否可以接受

在某些情况下，这是设计方案，是所有目标之间的最佳权衡，但这取决于具体情况。竞争目标如下：

• 避免代码重复，测试代码可读性：从测试代码创建复杂对象会使测试代码变得复杂且需要大量维护。重新使用其他应用程序代码来创建这些对象可以简化测试代码，否则会以某种方式复制代码以创建对象
• 测试代码的可信度：如果您的测试代码依赖于其他组件，则测试结果的可信度会降低-测试失败可能是由于其他组件，通过测试可能是由于创建的对象具有与测试中预期不同的属性。请注意，如果函数作为公用设施使用，其本身经过彻底测试
• 测试套件的完整性：当使用实用程序函数创建输入对象时，存在一种风险，即在实用程序函数能够创建的测试期间，仅使用这些输入对象。也就是说，如果实用程序函数永远不会创建格式不正确的对象，那么您可能会限制您的测试，使您永远不会使用这些工具测试SUT格式错误的对象。如果您意识到这一风险，您当然仍然可以在使用格式错误的对象的情况下进行一些附加测试-但是，在这些测试中，您可以不使用实用程序功能
• 测试设置的复杂性、执行时间等：如果实用程序函数本身具有进一步的依赖性，或者它们编译、链接或执行缓慢，则会将所有这些缺点带入测试代码。因此，只有某些应用程序函数适合在测试代码中使用

我想到的一个例子是测试一个函数，该函数接收代数表达式的解析树作为输入，并对该表达式求值。假设同一个应用程序也有一个解析函数，该函数从字符串创建解析树

---

在求值函数的单元测试中使用parse函数在这里是一个很好的选择：表达式字符串在单元测试中可读性很好，parse函数可能只具有测试代码本身需要的依赖项（例如，解析树的节点和边的类）。解析预计不会对测试性能产生重大影响。此外，如果解析函数经过良好测试，则其在测试代码中的使用不会对可信度产生重大影响。尽管如此，仍有必要进行一些额外的测试，其中故意创建格式不正确的解析树来测试行为这种情况太长了，读不下去了，所以，在单元测试中，单独的方法不能及时满足要求，其中负责转换的类总是与需求相符合。这是数据，不要写新的。我会直接用bean类型来测试ClassB，而不是从CSV数据开始。你可以简单地模拟bean类型，但是如果这是不可接受的，如果除了使用ClassA创建bean之外没有其他方法，我会按照你的建议使用ClassA来创建ClassB测试输入。我不会复制cod你的答案是：）模拟将要在计算中使用的bean，因为对于ClassB，你只想检查它是否正确地计算了数据。可能首先将CSV转换为bean，然后进行计算的测试是一个集成测试（但我不确定这种类型测试的corect命名）。