Java(以及其他社区,我确定)是否应该测试琐碎的getter/setter方法,这是一个众所周知的争论.通常,这与代码覆盖有关.让我们同意这是一场公开辩论,而不是试图在这里回答.
有几篇关于使用Java反射来自动测试这些方法的博客文章.
是否有任何框架(例如jUnit)提供这样的功能?例如,一个注释说"这个测试T应该自动测试C类的所有getter/setter,因为我声称它们是标准的".
在我看来,它会增加价值,如果它是可配置的,那么"辩论"将留给用户作为选项.
我不知道有任何现成的库或类可以做到这一点.这可能主要是因为我不在乎,因为我坚决反对这样的测试.所以即使你问这个观点必须有一些理由:
我怀疑自动测试的getter和setter是否有益于你的代码质量或覆盖范围:这些方法都可以从其他代码中使用(并在那里进行测试,例如100%覆盖)或根本不使用(并且可以删除).最后,您将留下getter和setter,因为它们是从测试中使用的,但在应用程序中没有其他地方.
编写这样的测试应该很容易,例如使用Apache Commons BeanUtils,但是如果你有其他好的测试,我怀疑你真的需要它.
我创建了OpenPojo项目来解决这个确切的问题.
该项目允许您验证:
强制执行Pojo编码标准(即所有字段都是私有的,或者没有本机变量,等等)
强制执行Pojo行为(即setter执行JUST设置,不进行转换等)
验证Pojo标识(即使用基于注释的相等和哈希码生成)
请参阅教程
Unitils用静态方法做这件事assertRefEquals
.
在大多数情况下,setter和getter只做设置和获取内部字段.对象必须检查其仅包含有效值的内部规则.例如
可能是空值吗?
可能是空字符串吗?
或负值?
或零值?
或列表中的值是否有效?
或者是否有最大值?
或BigDecimal值是否有最大精度?
如果存在无效值,单元测试应检查行为是否正确.这不能自动化.
如果你在setter和getter上没有逻辑,那么它必须在你的应用程序的任何地方使用.编写测试,其中对象是更复杂测试的参数.您可以使用列表中的不同值对其进行测试.
测试您的业务逻辑而不是getter和setter.结果还应该覆盖getter和setter.如果您只有一个公共库,那么这些方法也应该是您的业务逻辑中的任何结果.如果getter和setter没有代码覆盖,则将其删除.
我做过类似的事.一个简单的java类,它接受一个对象并测试所有getter和setter方法. http://sourceforge.net/projects/getterandsetter/
我认为你应该尽可能地避免使用getter和setter方法,但只要它们存在并且需要两行来测试它们,那么这样做是件好事.