那需要吗？

解决方案

Pojos可能仍然包含逻辑错误。

如果尚未测试，则可能有错误！ ;)

当然是需要的。所有必须工作的代码都必须经过测试。

当然，我们还要对测试用例进行哪些处理？

我喜欢进行测试驱动开发，这与测试Pojo息息相关(嗯，实际上是关于设计Pojo息)。

通常。如果模型无法按预期工作，那么我们将遇到很多麻烦……

从好的方面来说，测试它们要容易得多。

如果PoJos包含对业务很重要的逻辑，那么可以，当然要对其进行测试。

如果他们不这样做，那就不要打扰。有时让班级不进行测试很重要，因为它使我们可以自由地稍后重构它。

我为除简单的getter和setter之外的所有内容编写了显式测试。

如果getter或者setter只包含返回等等；或者this.blah = blah;我认为没有太大的价值。在大多数情况下，这些都是生成的，我认为将测试组合在一起的时间可能会花在其他地方。

除了getter和setter之外，我都这样做。我们必须在某处画线。

当然，如果它们包含"关键任务"代码，则需要对其进行测试。

说"当然"很容易。但是，这是为什么的原因：在实际的软件中，我们具有逐层的组件。可以很容易地说出堆栈底部的小pojo太小而没有实际错误，但是当我们在软件中遇到意外结果时，如果我们将所有涉及的代码进行了全面测试，则最终结果是与整个叠叠的犯罪嫌疑人。

但是，如果在基础功能之上构建高级功能之前先进行测试，则当出现问题时，我们会知道要看的地方(即，在基础程序上重新运行测试以进行测试后，确保某些内容没有改变)。

还请记住，为pojos编写测试应该相对容易，因为模块提供的功能越少，测试的内容就越少。

我确实同意不测试吸气剂和吸气剂。

通常，POJO在某些情况下进行测试。如果要执行某些逻辑，则必须正确测试(理想情况下，在开始该逻辑实现之前)。至于吸气剂和吸气剂；通常不需要测试它们，因为可以通过测试逻辑来获得覆盖率：-)尝试检查一些覆盖率报告工具，例如Cobertura，Clover或者尝试Emma并查看需要测试的内容。我非常喜欢三叶草的报告，该报告显示了代码中最危险的威胁。

我认为这个问题在术语上有些混乱。 POJO(普通的旧Java对象)是指不受特定应用程序服务器或者第三方库的依赖所影响的Java对象。使用像Spring这样的好的IOC(控制反转)框架，我们可以将所有类编写为POJO，这样就可以独立测试它们而不必在测试中启动应用服务器。

Java bean是一个简单的Java类，包含私有属性和公共getBlah()和setBlah()访问器方法，仅包含其他内容。 Java bean本质上是POJO。

因此，如果问题是："我应该测试我的POJO(包含业务逻辑)吗？"答案是肯定的。

如果问题是："我应该测试我的Java bean(它们是没有行为的简单值对象)吗？"答案可能不是。

不，我不测试POJO，因为：

1.如果POJO包含业务逻辑，则从POJO中提取它，然后进行测试。但是该测试已经超出了POJO的范围。

2.如果POJO不包含它，即simple / getters / setters方法，则在构建时或者运行时(CGLIB)动态生成它。因此，我测试了我的代码生成器，但没有测试我的POJO。

因此，正如这里其他所有人所提到的，是的，我们需要对其进行测试。但是，如果我们是由于TDD的设计需求而创建的，则我们会发现，一旦运行代码覆盖工具，这些POJO(或者我们的.net peoc的POCO)实际上将被覆盖。这是因为TDD仅允许我们编写/重构由某些单元测试驱动的代码。

这就是使TDD比单元测试更好的原因，恕我直言。

好吧，人们似乎已经忽略了另一个维度。

是的，当我们想到POJO时，唯一想到的就是带有相应的getter和setter的属性。但是，除此之外，POJO还可以借助重写的equals()和hashCode()方法对Collections做出同样的贡献。 :)在这种情况下，我的POJO应该接受体面的测试！ :)

我们应该使用不同的可能值进行多次测试，并确保equals()和hashCode()组合不提供重复的值！