Question

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

另见

Is it bad practice to run tests on a DB instead of on fake repositories?

Is there a Java unit-test framework that auto-tests getters and setters?

Answer 1

TDD中的规则是"Test everything that could possibly break"吸气剂是否会中断？一般不会，所以我不打算去测试它。此外，代码I 做测试肯定会调用getter，因此将进行测试。

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

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

Answer 2

POJO还可以包含其他函数，例如equals（），hashCode（），compareTo（）和各种其他函数。了解这些功能是否正常工作可能很有用。

Answer 3

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

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

Answer 4

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

int getX()
{
    return (x);
}

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

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

Answer 5

我使用IntelliJ作为IDE，它几乎为我写了琐碎的POJO - 当然是构造函数和getter / settors。我没有看到单元测试中有任何意义，因为任何错误都可能出现在我编写的测试代码中。

Answer 6

根据我的经验，仅使用getter和setter为POJO创建单元测试，实在是太过分了。当然，有一些例外，如果getter / setter中有额外的逻辑，比如检查null和做一些特殊的事情，那么我会为它创建一个单元测试。

另外，如果POJO中存在错误，我会为它创建一个单元测试，这样我们就可以防止它再次发生。

Answer 7

确保你没有写

，这可能值得一个简单的测试

public void setX(int x) {
   x = x;
}

虽然您应该编码以避免这种情况（通过在方法参数上添加final修饰符，或类似）。这也取决于你如何生成访问者，以及他们是否会遇到复制/粘贴错误等（即使在试图强制使用IDE的环境中也会发生这种情况 - 它会发生这种情况）。

然而，我对包含大量setter / getter的类的主要关注是正在做什么的类？对象应该为你做的东西，而不仅仅是保持和返回数据。如果这些是数据实体对象，那么setter / getter模式可能是正确的。然而，更好的模式是设置对象中的数据，并要求对象用它做事（计算你的银行余额，启动火箭等）而不是返回数据并让你自己做！

Answer 8

我的回答是琐碎的吸气剂和制定者不值得他们自己的测试。如果我添加除简单读取或写入之外的任何代码，那么我添加测试。

当然，这都是样板文件，所以你可以轻松编写一个脚本，为你的getter和setter生成单元测试，如果你认为那里有任何价值。某些IDE可能允许您定义一个模板，该模板使用为此样板代码填充的测试方法创建测试用例（我在这里考虑IntelliJ，但Eclipse也可以处理它，尽管我也没有做过这样的事情。 IDE）。

Answer 9

单元测试不仅验证代码是否正常工作，而且还记录了预期的行为。我不知道有多少次我看到事情有所破坏，因为有些时候，有人改变了POJO中吸气剂或固定剂的行为，然后意外地破坏了其他东西（例如，有人为设定者添加了逻辑）如果有人在字符串上设置了空值，则setter会将其更改为空字符串，以便不会发生NPE）。

我不认为数据存储POJO的单元测试是浪费时间，我将它们视为未来维护的安全网。话虽这么说，如果你手动编写测试来验证这些对象，那么你就是这么做的。看看http://gtcgroup.com/testutil.html

之类的内容

Answer 10

有一个开源实用程序http://meanbean.sourceforge.net/，可以让您测试POJO。还有一个页面描述了这个实用程序提供的优点/问题及其使用原因。

我自己也从未厌倦过，但它已被推荐给我了。

Answer 11

当测试任何功能的逻辑时，会自动测试IMHO POJO，例如，为了测试任何函数，我们可能需要注入/模拟某些值，POJO和POJO的getter / setter是间接测试的。

然而，对于消除POJO进行单元测试的特定用例，可以通过以下两种方式实现：

USE LIBRARY：使用有助于测试POJO的现有库。我遇到的一个这样的图书馆是meanbean。

参考：http://meanbean.sourceforge.net/

Maven ：http://mvnrepository.com/artifact/org.meanbean/meanbean（当前版本：2.0.3）

IGNORE POJO：可以将Sonar配置为排除POJO或要从单元测试覆盖率报告中排除的特定包。以下几个例子：

<properties>
    <sonar.coverage.exclusions>
        **/domain/**/*,
        **/pojos/*
    </sonar.coverage.exclusions>
</properties>

Answer 12

我正在尝试使用cobatura进行代码覆盖，并且遇到了同样的问题。

最好有一个注释添加到类中，表示不在代码覆盖中包含此类。但是，可以将您的pojo放在一个单独的包中，然后从分析中排除该包。

根据您的工具查看文档，它适用于Ant，Maven或命令行。

Answer 13

我刚刚开始实施这个项目。它现在处于前阿尔法阶段。它是一个Eclipse插件。

虽然我同意POJO setter / getter通常不一定需要测试，但我相信在那里进行简单的测试是很好的，因为随着时间的推移，事情会随着时间的推移而变化，这将使您更容易添加更多的测试对于POJO来说。设置单元测试，方法是测试setter / getter，你所要做的就是处理新的复杂性。

这也有助于代码覆盖率报告，这有助于让管理者满意。（我的公司使用艾玛）。

https://sourceforge.net/projects/unittestgplugin/

Answer 14

使用Lombok库可以解决此问题，该库消除了所有这些样板代码以及equals和hashcode。

所以除非你对equals和hashcode有特定要求，否则你不需要测试它们

https://projectlombok.org/

Answer 15

MeanBean库提供了一个用于测试POJO的API。例如，下面的代码片段测试了Emplooyee pojo。演示应用link.

BeanTester beanTester = new BeanTester();
beanTester.testBean(Employee.class);

Answer 16

您希望知道的单元测试代码（当然，对于测试的情况）。不要单独测试代码，你只想确定有效。

我想不出太多我只想确定一下。

Answer 17

我认为如果使用IDE创建了getter和setter，那么应该没问题。我们还有其他东西可以放入代码。显然，您将测试POJO的序列化/反序列化。

JUnit测试POJO

17 个答案: