JUnit测试POJO
我在一个项目上工作，我们必须为所有简单的bean（POJO）创建unit testing。 如果所有POJO都是getter和setter，那么为POJO创建unit testing是否有任何意义？ 假设POJO在100％的时间内都能正常工作，这是一个安全的假设吗？
重复 – 应该测试@Entity Pojos吗？
也可以看看
在数据库而不是假存储库上运行测试是不好的做法吗？
是否有一个Javaunit testing框架可以自动测试getter和setter？
TDD中的规则是“测试可能会破坏的一切”吸气剂能否突破？ 一般不会，所以我不打算去测试它。 此外，我测试的代码肯定会调用getter，因此它将被测试。
我个人的规则是，我会为任何做出决定的函数编写一个测试，或者做一个不仅仅是一个微不足道的计算。 我不会为i+1编写测试，但我可能会为if (i<0)...而且肯定会为(-b + Math.sqrt(b*b - 4*a*c))/(2*a) 。
顺便说一下，对POJO的强调背后有不同的原因。 我们希望将大量代码写入POJO， 而不依赖于它们运行的环境 。 例如，测试servlet很困难，因为它们依赖于在容器内执行。 因此，我们希望servlet调用不依赖于其环境的POJO，因此易于测试。
POJO还可以包含其他函数，例如equals（），hashCode（），compareTo（）和各种其他函数。 知道这些function正常工作可能很有用。
我认为测试简单的属性getter和setter是没有意义的。 unit testing的重点不是validation编译器是否正常工作。
但是，只要向getter和setter（或其他方法）添加条件，null检查或其他非平凡的行为，我认为添加unit testing是合适的。
我曾经花了两个小时因为这样的事情：
int getX() { return (x); } int getY() { return (x); // oops }
由于几乎没有时间为简单的吸气剂编写测试，我现在就习惯了。
我使用IntelliJ作为IDE，它几乎为我写了琐碎的POJO – 当然是构造函数和getter / settors。 我没有看到unit testing中有任何意义，因为任何错误都可能出现在我编写的测试代码中。
我的答案是，琐碎的吸气剂和制定者不值得他们自己的测试。 如果我添加除简单读取或写入之外的任何代码，那么我添加测试。
当然，这都是样板文件，因此您可以轻松编写一个脚本，为您的getter和setter生成unit testing，如果您认为那里有任何值。 某些IDE可能允许您定义一个模板，该模板使用为此样板代码填充的测试方法创建测试用例（我在这里考虑IntelliJ，但Eclipse也可以处理它，尽管我在这两个方面都没有做过这样的事情。 IDE）。
根据我的经验，仅使用getter和setter为POJO创建unit testing，实在是太过分了。 当然，有一些例外，如果getter / setter中有额外的逻辑，比如检查null和做一些特殊的事情，那么我会为此创建一个unit testing。
另外，如果POJO中存在错误，我会为它创建一个unit testing，这样我们就可以防止它再次发生。
这可能值得一个简单的测试，以确保你没有写
public void setX(int x) { x = x; }
虽然您应该编码以避免这种情况（通过在方法参数上添加final修饰符，或类似）。 它还取决于您如何生成访问器，以及它们是否可能遭受复制/粘贴错误等（即使在尝试强制使用IDE的环境中也会发生这种情况 – 它会发生）。
然而，我对包含大量setter / getter的类的主要关注是该类正在做什么 ？ 对象应该为你做的东西，而不仅仅是持有和返回数据。 如果这些是数据实体对象，那么setter / getter模式可能是正确的。 然而，更好的模式是设置对象中的数据，并要求对象用它做事（计算你的银行余额，启动火箭等）而不是返回数据并让你自己做！
unit testing不仅validation代码是否正常工作，还记录了预期的行为。 我不知道有多少次我看到事情有所破坏，因为有些时候，有人改变了POJO中吸气剂或设定者的行为，然后意外地破坏了其他东西（例如，有人为设定者添加了逻辑）如果有人在字符串上设置了空值，则setter会将其更改为空字符串，以便不会发生NPE）。
我不认为数据存储POJO的unit testing是浪费时间，我将它们视为未来维护的安全网。 话虽如此，如果您手动编写测试来validation这些对象，那么您正在以艰难的方式进行。 看看像http://gtcgroup.com/testutil.html这样的东西
有一个开源实用程序http://meanbean.sourceforge.net/ ，它允许您测试POJO。 还有一个页面描述了一个可能对此实用程序提供的内容以及应该使用它的原因的优点/问题。
我自己也从未厌倦过，但它已被推荐给我了。
我正在尝试使用cobatura进行代码覆盖，并且遇到了同样的问题。
如果有一个注释要添加到类中，并且在代码覆盖率中不包含此类，那将会很高兴。 但是，可以将pojo放在单独的包中，然后从分析中排除该包。
根据您的工具查看文档，它适用于Ant，Maven或命令行。
我刚刚开始实施这个项目。 它现在处于前阿尔法阶段。 它是一个Eclipse插件。
虽然我同意通常POJO setter / getter不一定需要测试，但我相信在那里进行简单的测试是很好的，因为随着时间的推移，它会让你更容易为POJO添加更多的测试。 设置unit testing，方法是测试setter / getter，你所要做的就是处理新的复杂性。
这也有助于代码覆盖率报告，这有助于让管理者满意。 （我的公司使用艾玛）。
-
USE LIBRARY：使用有助于测试POJO的现有库。 我遇到的一个这样的图书馆是meanbean。
参考 ： http ： //meanbean.sourceforge.net/
Maven ： http ：//mvnrepository.com/artifact/org.meanbean/meanbean（当前版本：2.0.3）
-
IGNORE POJO：可以将Sonar配置为排除POJO或要从unit testing覆盖率报告中排除的特定包。 以下几个例子：
**/domain/**/*, **/pojos/*
通过使用Lombok库可以解决此问题，该库消除了所有这些样板代码以及equals和hashcode。
因此，除非您对equals和hashcode有特定要求，否则无需测试它们
您想知道的unit testing代码有效（当然，对于测试的情况）。 不要unit testing代码，你只想确保工作。
我想不出太多我只想确定一下。
我想如果使用IDE创建了getter和setter，那么它应该没问题。 我们还有其他东西可以放入我们的代码。 显然，您将测试POJO的序列化/反序列化。