是否有自动测试 getter 和 setter 的 Java 单元测试框架？

Is there a Java unit-test framework that auto-tests getters and setters?

提问by Michael Easter

There is a well-known debate in Java (and other communities, I'm sure) whether or not trivial getter/setter methods should be tested. Usually, this is with respect to code coverage. Let's agree that this is an open debate, and not try to answer it here.

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

There have been several blog posts on using Java reflection to auto-test such methods.

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

Does any framework (e.g. jUnit) provide such a feature? e.g. An annotation that says "this test T should auto-test all the getters/setters on class C, because I assert that they are standard".

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

It seems to me that it would add value, and if it were configurable, the 'debate' would be left as an option to the user.

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

采纳答案by Kevin Wong

Unitilsdoes this w/ the static method assertRefEquals.

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

回答by Olaf Kock

I'm not aware of any readily available library or class that does this. This may mainly be because I don't care as I am on the side of strongly opposing such tests. So even though you asked there mustbe a bit of justification for this view:

我不知道有任何现成的库或类可以做到这一点。这可能主要是因为我不在乎，因为我强烈反对此类测试。因此，即使您问过这种观点，也必须有一些理由：

I doubt that autotesting getters and setters benefit your code quality or your coverage: Either these methods are used from other code (and tested there, e.g. 100% covered) or not used at all (and could be removed). In the end you'll leave getters and setters in because they are used from the test but nowhere else in the application.

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

It should be easy to write such a test, e.g. with Apache Commons BeanUtils, but I doubt you really need it if you have good tests otherwise.

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

回答by philant

I'll favor OO design over code coverage, and see if I cannot move those fields to the class that needs them. So I would try to see if those getters and setters can be removed, as suggested before. getters and setters are breaking encapsulation.

我更喜欢面向对象设计而不是代码覆盖，看看我是否不能将这些字段移动到需要它们的类中。所以我会尝试看看是否可以像之前建议的那样删除这些 getter 和 setter。getter 和 setter 正在打破封装。

回答by Horcrux7

In the most cases setter and getter do more as only setting and getting an internal field. An Object has to check internal rules that it hold only valid values. For example

在大多数情况下，setter 和 getter 做的更多只是设置和获取内部字段。一个对象必须检查它只保存有效值的内部规则。例如

• are null values possible?
• are empty strings possible?
• or negative values?
• or a zero value?
• or values from a list are valid?
• or is there a maximal value?
• or is there a maximum precision on BigDecimal values?

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

The unit test should check if the behavior correct if there invalid values. This can not be automated.

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

If you have no logic on the setter and getter then it must be used anywhere in your application. Write a test where your object is a parameter for a more complex test. You can test it then with different values from the list.

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

Test your business logic and not the getter and setter. The result should also a coverage of the getter and setter. The methods should be any result in your business logic also if you have only a public library. If the getter and setter have no code coverage then removed it.

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

回答by Daniel Fanjul

Answering the previous comment at @mehere because of my reputation:

由于我的声誉，在这里回答@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?

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

Well, sometimes, there is no need to the field be private (Sorry if my English is not very good). Often, we write our software as it was a library and we encapsulate our fields (our business logic fields) with unnecessary getters/setters.

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

Other times, that methods are actually necessary. Then, there are two possibilities:
1. There is business logic inside them. Then they sould be tested, but they aren't real getters/setters. I always write that logic in other classes. And the tests test that other classes, not the POJO.
2. There is not. Then, do not write them by hand, if you can. For example, an implementation for the next interface may be fully autogenerated (and also in runtime!) :

其他时候，这些方法实际上是必要的。那么，有两种可能：
1.里面有业务逻辑。然后他们应该接受测试，但他们不是真正的吸气剂/二传手。我总是在其他类中编写该逻辑。并且测试测试的是其他类，而不是POJO。
2. 没有。然后，如果可以，不要手写它们。例如，下一个接口的实现可能是完全自动生成的（并且也在运行时！）：

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

So test only what is written by hand. No matter if it is a getter/setter.

所以只测试手写的内容。不管它是一个 getter/setter。

回答by Daniel Fanjul

I've done something like that. A simple java class that takes an object and test all the getters and setter methods. http://sourceforge.net/projects/getterandsetter/

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

I do think you should avoid getter and setter methods as much as possible, but as long as they're around and it takes two lines to test them, it's a good thing to do it.

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

回答by maasha

I am trying out openpojo

我正在尝试 openpojo

I have kicked the tires and it seems to do the job.

我已经踢了轮胎，它似乎完成了这项工作。

1. It allows you to check all the pojo's in your project.
2. It seems to check the best practices on pojo's

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

Check this tutorial for a quick start Tutorial

查看本教程以获取快速入门 教程

回答by Osman Shoukry

I created the OpenPojoproject for solving this exactproblem.

我创建了OpenPojo项目来解决这个确切的问题。

The project allows you to validate:

该项目允许您验证：

• Enforce Pojo coding standard (i.e. All fields private, or no native variables, ...etc)
• Enforce Pojo behaviour (i.e. setter does JUST setting, no transformation, etc)
• Validate Pojo Identity (i.e. Use annotation based equality & hashcode generation)

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

See Tutorial

见教程

回答by Franck Valentin

I guess this library is the answer to your question

我想这个图书馆是你问题的答案

it tests all the bean's initial values, the setters, the getters, hashCode(), equals() and toString(). All you have to do is define a map of default and non default property/value.

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

It can also test objects that are beans with additional non default constructors.

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

回答by Zim

I don't write test cases for each property, but instead test all of the setters/getters in a single test case using reflection/introspector to determine the type(s). Here is a great resource that shows this:

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

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

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