在Java(我敢肯定，在Java和其他社区中)之间存在着一个众所周知的争论，即是否应该测试简单的getter / setter方法。通常，这是关于代码覆盖率的。我们同意这是一场公开辩论，而不是在这里尝试回答。

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

是否有任何框架(例如jUnit)提供这种功能？例如注释为"该测试T应该自动测试类C上的所有吸气剂/设置器，因为我断言它们是标准的"。

在我看来，这将增加价值，如果它是可配置的，则"辩论"将留给用户选择。

解决方案

我不知道有任何现成的库或者类可以做到这一点。这可能主要是因为我不在乎我是否坚决反对此类测试。因此，即使我们问过这种观点也有一定道理：

我怀疑自动测试获取器和设置器是否会提高代码质量或者覆盖范围：这些方法是从其他代码中使用(并在此处进行测试，例如100％被覆盖)还是根本没有使用(可以删除)。最后，我们将保留getter和setter，因为它们是在测试中使用的，而在应用程序中没有其他地方。

编写这样的测试应该很容易，例如与Apache Commons BeanUtils一起使用，但是如果我们进行了良好的测试，我怀疑我们是否真的需要它。

与代码覆盖率相比，我更倾向于OO设计，然后看看是否无法将这些字段移到需要它们的类中。因此，我将尝试看看是否可以像以前建议的那样删除那些吸气剂和吸气剂。
getter和setter破坏了封装。

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

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

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

如果在setter和getter上没有逻辑，则必须在应用程序中的任何地方使用它。编写一个测试，将对象作为更复杂测试的参数。然后可以使用列表中的其他值对其进行测试。

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

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

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

Vlookward, not writing getters/setters makes no sense at all. The only options for setting private fields is to have explicit setters, to set them in your constructor, or to set the indirectly via other methods (functionally deferring the setter to another place). Why not use setters?

好吧，有时候，不需要将该字段设为私有(很抱歉，如果我的英语不太好)。通常，我们将软件作为一个库来编写，并且用不必要的getter / setter封装我们的字段(我们的业务逻辑字段)。

在其他时候，该方法实际上是必需的。然后，有两种可能性：
1.他们内部有业务逻辑。然后他们将受到考验，但他们并不是真正的吸气手。我总是在其他课堂上写这种逻辑。测试将测试其他类，而不是POJO。
2.没有。然后，如果可以的话，请不要手写。例如，下一个接口的实现可以完全自动生成(并且也可以在运行时！)：

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

因此，仅测试手写的内容。不管它是吸气剂还是吸气剂。

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

我确实认为我们应该尽可能避免使用getter和setter方法，但是只要它们存在并且需要两行代码对其进行测试，那么这样做是一件好事。