Question

编写Java类时，使用IDE生成方法并不罕见，例如

toString()
equals()
hashCode()

但是一旦您使用IDE生成它们，它们就会成为您的代码库的一部分（在SCM中），因此所有质量测量方法都适用。

特别是equals和hashcode方法包含很多条件。如果我不编写单元测试，代码覆盖率（线条，条件，变异）的得分相当低，特别是如果被测试的类不那么大。

一些覆盖工具支持过滤（即cobertura），其他（即jacoco）不支持。但覆盖工具只显示了一个症状 - 未经测试的代码 - 因此我不是在问，是否要抑制/忽略症状，而是如何处理根本原因。

问题是：我应该为这些方法编写单元测试吗？

如果是，有什么理由这样做？什么是明智的做法？
如果不是，为什么不呢？

我并不是要求生成一般的类，比如JAXB pojos，WS-Clients等，它们可以很容易地自动生成并从覆盖率分析中排除。

Answer 1

如果您生成这些方法，您可能也应该为它生成测试; - ）

手动测试这些方法可能很麻烦，但根据您希望通过测试确保的方法，测试这些方法也许值得。反问题：你会测试日志声明吗？

这实际上取决于你想要完成的事情。有些人会说：不要，其他人可能会说：做。

考虑不测试此类方法的一些原因：

生成代码，可能包含大量字段。测试它可能导致许多各种组合，这些组合只是编写/维护很麻烦，也许发电机已经测试好了吗？ ; - ）
通过实施测试，你没有获得任何价值。您的toString()只会被日志或调试人员使用，因此您甚至无需关心。
您相信生成的代码对hashcode和equals

测试此类方法的原因：

确保结果符合预期
您希望确保如果重新生成这些方法，则不会破坏以前的方法实现用法
除了记录之外，您还使用了toString() - 方法，并且不希望某些内容显示在那里。正如Hulk所说，你可能还想确保某些东西甚至不会出现在日志中。

但这些都是相当弥补的。在上一个项目中，我没有对toString()和equals或hashCode进行测试，因为它们没有被认为是必要的并且每个人都同意。

这可能归结为：您希望代码的安全性以及对您（或您的企业或客户有多少价值; - ）

Answer 2

IDE生成的hashCode / equals的问题是它可能与对象本身不同步（例如，当您添加新字段时）。因此，我建议为hashCode和equals创建测试。

手工编写这些文件当然是次优的。您可以使用EqualsVerifier项目等自动化工具将这些工具设为一行。

toString是一个不同的野兽，因为它没有定义任何合同。如果你只是为了获得更好的调试体验而使用toString，我就不会对它进行测试，只是将其从覆盖率计算中删除。

Answer 3

是的，我将测试所有这些。不足以说，因为它们是自动生成的，所以不需要测试。有人可以轻松地添加一个新字段，而忘记重新生成equals /哈希码和字符串。

测试字符串可能是最有争议的，但是我认为这是必需的，尤其是在登录应用程序时。

正如其他人已经建议的那样，EqualsVerifier可能是测试等于和哈希码的最佳方法。

关于测试toString方法，请尝试ToStringVerifier。测试很简单：

@Test
public void testToString()
{
    ToStringVerifier.forClass(User.class)
                  .withClassName(NameStyle.SIMPLE_NAME)
                  .verify();
}

Answer 4

这些方法本身毫无用处。如果您不在集合中使用这些类（例如HashSet / HashMap），或者您从未检查过这些类实例是否相等 - 那么您就不需要进行单元测试。而且，在这种情况下，我会禁用生成它们的插件，就像@ByeBye提出的那样。

但是，如果您真的这样做，则需要进行单元测试。如果不正确的实现可能导致应用程序失败或行为不正确 - 必须通过单元测试来实现此实现。

Answer 5

外部库相同 - 生成时不应测试equals和hashcode方法。检查覆盖范围的插件应该有一些机制来忽略生成的源。

没有充分的理由来测试生成的代码，如果这是您的类或整个类中生成的方法没有区别。

如果你依赖外部机制，你应该相信它是正确创造的。

我应该单元测试hashCode / equals / toString吗？

5 个答案: