除了简单的getter和setter之外,我会为所有内容编写明确的测试。
如果getter或setter仅包含return blah;或this.blah = blah;,我认为价值不大。这些大多数情况下都是自动生成的,我觉得把时间放在其他地方更有意义。
如果您的PoJos(Java普通对象)包含对业务重要的逻辑,那么当然需要测试。
如果它们没有包含业务逻辑,那么就不必费心。有时候,留下一个没有测试的类很重要,因为这样可以让您在以后自由地重构它。
然而,如果你在构建更高级别的功能之前测试你的低级别例程,当出现问题时,你就知道该去哪里寻找(也就是在重新运行低级别例程的测试以确保没有发生变化后)。
还要记住,为你的pojos编写测试应该相对容易,因为模块提供的功能越少,需要测试的内容就越少。
我同意不测试getter和setter。
嗯,人们似乎忽略了另一个维度。
是的,当你想到POJO时,任何人脑海中想到的只有相应的获取器和设置器属性。但是,除此之外,POJO还可以通过覆盖equals()和hashCode()方法在集合中同样发挥作用。:) 在这种情况下,我的POJO值得经过适当的测试!:)
您应该使用不同可能的值测试多次,并确保equals()和hashCode()组合不提供重复值!
除了Getter和Setter,我是支持这种做法的。你必须在某个地方划定界限。
所以,像这里其他人提到的一样,你需要测试它们。但是,如果你通过TDD来满足设计需求创建了它们,你会发现,一旦运行代码覆盖工具,那些POJO(或对于我们.net peeps来说是POCOs)将会被覆盖。这是因为TDD只允许你编写/重构由某个单元测试驱动的代码。
在我看来,这就是TDD比单元测试更好的原因。
即使是“普通”的getter和setter,你也需要这样做,原因如下:
虽然有一个自动生成这些测试的工具会很好...
POJO(普通 Java 对象)仍然可能包含逻辑错误。