Question

在Java（以及其他社区，我确定）中是否存在一个众所周知的争论，即是否应该测试琐碎的getter / setter方法。通常，这与代码覆盖有关。让我们同意这是一场公开辩论，而不是试图在这里回答。

有几篇关于使用Java反射来自动测试此类方法的博客文章。

是否有任何框架（例如jUnit）提供此类功能？例如一个注释说“这个测试T应该自动测试C类上的所有getter / setter，因为我断言它们是标准的”。

在我看来，它会增加价值，如果它是可配置的，那么'辩论'将留给用户作为选项。

Answer 1

我不知道有任何现成的库或类可以做到这一点。这可能主要是因为我不在乎，因为我坚决反对这样的测试。所以，即使你问过必须对这个观点有点理由：

我怀疑自动测试的getter和setter是否有益于您的代码质量或覆盖范围：这些方法都可以从其他代码中使用（并在那里进行测试，例如100％覆盖）或根本不使用（并且可以删除）。最后，您将留下getter和setter，因为它们是从测试中使用的，但在应用程序中没有其他地方。

编写这样的测试应该很容易，例如使用Apache Commons BeanUtils，但如果你有其他好的测试，我怀疑你真的需要它。

Answer 2

我创建了OpenPojo项目来解决此完全问题。

该项目允许您验证：

强制执行Pojo编码标准（即所有字段为私有，或无本地变量，等等）
强制执行Pojo行为（即setter执行JUST设置，不进行转换等）
验证Pojo身份（即使用基于注释的相等和哈希码生成）

See Tutorial

Answer 3

Unitils使用静态方法assertRefEquals执行此操作。

Answer 4

在大多数情况下，setter和getter只做设置和获取内部字段。对象必须检查其仅包含有效值的内部规则。例如

是否可以为空值？
可能是空字符串吗？
或负值？
或零值？
或列表中的值是否有效？
或者是否有最大值？
或BigDecimal值是否有最大精度？

如果存在无效值，单元测试应检查行为是否正确。这不能自动化。

如果你在setter和getter上没有逻辑，那么它必须在你的应用程序的任何地方使用。编写测试，其中对象是更复杂测试的参数。您可以使用列表中的不同值对其进行测试。

测试您的业务逻辑，而不是getter和setter。结果还应该覆盖getter和setter。如果您只有公共库，那么这些方法也应该是您的业务逻辑中的任何结果。如果getter和setter没有代码覆盖，则将其删除。

Answer 5

我做过类似的事情。一个简单的java类，它接受一个对象并测试所有getter和setter方法。 http://sourceforge.net/projects/getterandsetter/

我确实认为你应该尽可能地避免使用getter和setter方法，但只要它们存在并且需要两行来测试它们，这样做是件好事。

Answer 6

我赞成OO设计而不是代码覆盖，看看我是否无法将这些字段移动到需要它们的类中。所以我会尝试看看是否可以删除这些getter和setter，如前所述。 getter和setter是breaking encapsulation。

Answer 7

I am trying out openpojo

我已经踢了轮胎，似乎可以胜任。

它允许您检查项目中的所有pojo。
似乎检查了pojo的最佳实践

查看本教程以快速入门 Tutorial

Answer 8

I guess this library is the answer to your question

它会测试所有bean的初始值，setters，getters，hashCode(), equals() and toString()。您所要做的就是定义默认和非默认属性/值的地图。

它还可以测试具有其他非默认构造函数的bean对象。

Answer 9

由于我的声誉，在@me回答了之前的评论：

Vlookward，不写getter / setter完全没有意义。设置私有字段的唯一选项是使用显式setter，在构造函数中设置它们，或者通过其他方法间接设置（在功能上将setter推迟到另一个地方）。为什么不使用setter？

嗯，有时，这个领域没有必要是私人的（对不起，如果我的英语不是很好）。通常，我们编写软件，因为它是一个库，我们用不必要的getter / setter封装我们的字段（我们的业务逻辑字段）。

其他时候，这些方法实际上是必要的。然后，有两种可能性：
1.内部有业务逻辑。然后他们会被测试，但他们不是真正的吸气者/制定者。我总是把这个逻辑写在其他类中。测试测试其他类，而不是 POJO 没有。然后，如果可以的话，不要手工编写。例如，下一个接口的实现可以完全自动生成（也可以在运行时！）：

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

因此，只测试手写的内容。无论是吸气剂还是吸气剂。

Answer 10

我不为每个属性编写测试用例，而是使用reflection / introspector在单个测试用例中测试所有setter / getter来确定类型。这是一个很好的资源，显示了这一点：

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unit_test_getters.html

是否有一个Java单元测试框架可以自动测试getter和setter？

10 个答案: