需要吗？
答案 0 :(得分：7)
我为除了简单的getter和setter之外的所有东西编写显式测试。
如果getter或setter只包含return blah;或者this.blah = blah;我认为没有多大价值。这些都是大部分时间产生的，我觉得将测试放在一起的时间可以更好地用于其他地方。
答案 1 :(得分：4)
我认为这个问题在术语上有点混淆。 POJO（Plain Old Java Object）是指不依赖于特定应用程序服务器或第三方库的Java对象。使用良好的IOC（Inversion Of Control）框架（如Spring），您可以将所有类编写为POJO，这样您就可以独立测试它们，而无需在测试中启动应用服务器。
Java bean是一个简单的Java类，包含私有属性和公共getBlah（）和setBlah（）访问器方法，而不是其他方法。 Java bean本质上是POJO。
因此，如果问题是“我应该测试我的POJO（包含业务逻辑）吗？”答案是肯定的。
如果问题是“我应该测试我的Java bean（这是没有行为的简单值对象）吗？”答案可能不是。
答案 2 :(得分：2)
如果您的PoJos包含对您的业务很重要的逻辑，那么当然可以测试它们。
如果他们不这样做，那就不要打扰了。有时离开一个没有测试的课程很重要，因为它可以让你自由地在以后重构它。
答案 3 :(得分：2)
很容易说“当然”。这就是为什么：在真实的软件中，你有一层层的组件。很容易说堆栈底部的小小pojos太小而不会出现真正的错误，但是当你在软件中遇到意想不到的结果时，你加起来所有尚未经过全面测试的代码，你最终会整个Jenga堆的嫌犯。
但是，如果您在构建更高级别的功能之前测试较低级别的例程，那么当出现问题时，您就会知道在哪里查看（也就是说，在较低级别重新运行测试之后）确保某些事情没有改变的惯例。
另外请记住，为pojos编写测试应该相对容易，因为模块提供的功能越少，测试的次数就越少。
我同意不测试getter和setter。
答案 4 :(得分：1)
我做的除了吸气剂和二传手。你必须在某处画线。
答案 5 :(得分：1)
通常，POJO在某些情况下进行测试。如果你想执行一些必须正确测试的逻辑（理想情况下，在开始逻辑实现之前）。至于吸气者和制定者;测试它们通常是没有必要的，因为通过测试逻辑获得覆盖:-)尝试检查一些覆盖报告工具，如Cobertura，Clover或尝试Emma，看看需要测试什么。我真的很喜欢Clover的报告，显示代码中最危险的威胁。
答案 6 :(得分：1)
所以，正如这里的其他人都提到的那样，是的，你需要测试它们。但是，如果您是因为设计需要通过TDD创建它们，您会发现一旦运行代码覆盖工具，那些POJO（或者我们的。偷窥的POCO）实际上将被覆盖。这是因为TDD只允许你编写/重构由某些单元测试驱动的代码。
这使得TDD比单元测试更好，恕我直言。
答案 7 :(得分：1)
嗯，人们似乎已经忽略了另一个维度。
是的，当你想到POJO时，任何人都会想到的是具有相应的getter和setter的属性。但是，除此之外，POJO还可以在重写的equals（）和hashCode（）方法的帮助下同样在Collections中做出贡献。 :)在这种情况下，我的POJO值得进行体面的测试！ ：）
您应该使用不同的可能值测试不同的时间，并确保equals（）和hashCode（）组合不提供重复值！
答案 8 :(得分：0)
Pojos仍然可能包含逻辑错误。
答案 9 :(得分：0)
如果尚未经过测试，则有错误！ ;）
答案 10 :(得分：0)
当然需要它。必须测试所有必须工作的代码。
答案 11 :(得分：0)
当然，你还会做什么测试案例？
我喜欢做Test Driven Development而且它非常关于测试你的pojos（好吧，实际上是关于设计你的pojos）。
答案 12 :(得分：0)
典型地。如果你的模型不能按预期工作，你将会遇到很多麻烦......
从好的方面来说，测试它们要容易得多。
答案 13 :(得分：0)
当然，如果它们包含“关键任务”代码，您将需要测试它们。
答案 14 :(得分：0)
出于以下原因，即使对于“普通”的吸气者和制定者，你也需要这样做：
很高兴有一个工具来自动生成这些测试......
答案 15 :(得分：-1)
不，我不测试POJO，因为：
1.-如果POJO包含buseness逻辑，我从POJO中提取它，当然，我测试它。但是那个测试已经超出了POJO。
2.-如果POJO没有包含它，即simple / getters / setters方法，我会在构建时或运行时（CGLIB）动态生成它。所以我测试了我的代码生成器，但不是我的POJO。