JUnit测试POJO

我在一个项目上工作,我们必须为所有简单的bean(POJO)创建单元测试.如果所有POJO都是getter和setter,那么为POJO创建单元测试是否有任何意义？假设POJO在大约100%的时间内都能正常工作,这是一个安全的假设吗？

---

重复 - 应该测试@Entity Pojos吗？

也可以看看

在数据库而不是假存储库上运行测试是不好的做法吗？

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

1> 小智..：

---

TDD中的规则是"测试可能会破坏的一切" 吸气剂能否突破？一般不会,所以我不打算去测试它.此外,我的代码做测试肯定会调用吸气所以它会被测试.

我的个人规则是,我会为任何做出决定的函数编写一个测试,或者做一个不仅仅是一个微不足道的计算.我不会写一个测试i+1,但我可能会,if (i<0)...并且肯定会为(-b + Math.sqrt(b*b - 4*a*c))/(2*a).

顺便说一句,对POJO的强调背后有不同的原因.我们希望将大量代码写入POJO,而不依赖于它们运行的​​环境.例如,测试servlet很困难,因为它们依赖于在容器内执行.因此,我们希望servlet调用不依赖于其环境的POJO,因此易于测试.

---

如果您所在的公司坚持代码覆盖百分比,您可以使用Apache commons的BeanUtils创建一个通用的getter/setter测试.只需将它传递给类,获取所有getter和setter方法,使用一些方法名称比较来匹配它们.

---

将来有人可以为你的getter/setter添加一些逻辑,忘记调整测试,除非它们失败

2> Kevin Crowel..：

---

POJO还可以包含其他函数,例如equals(),hashCode(),compareTo()和各种其他函数.知道这些功能正常工作可能很有用.

3> David Carlso..：

---

我不认为测试简单的属性getter和setter是有意义的.单元测试的重点不是验证编译器的工作原理.

但是,只要向getter和setter(或其他方法)添加条件,null检查或其他非平凡的行为,我认为添加单元测试是合适的.

4> TofuBeer..：

---

我曾经花了两个小时因为这样的事情:

int getX()
{
    return (x);
}

int getY()
{
    return (x); // oops
}

由于几乎没有时间为简单的吸气剂编写测试,我现在就习惯了.

---

应该有自动生成的那些!:d

---

这个项目可能有助于编写单元测试 - https://github.com/orien/bean-matchers