Java POJO 的 JUnit 测试
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/674408/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JUnit tests for POJOs
提问by Ryan Thames
I work on a project where we have to create unit tests for all of our simple beans (POJOs). Is there any point to creating a unit test for POJOs if all they consist of is getters and setters? Is it a safe assumption to assume POJOs will work about 100% of the time?
我在一个项目中工作，我们必须为我们所有的简单 bean (POJO) 创建单元测试。如果 POJO 只包含 getter 和 setter，那么为 POJO 创建单元测试有什么意义吗？假设 POJO 将在大约 100% 的时间内工作是否是一个安全的假设？
Duplicate of - Should @Entity Pojos be tested?
See also
也可以看看
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?
采纳答案by Uncle Bob
The rule in TDD is "Test everything that could possibly break"Can a getter break? Generally not, so I don't bother to test it. Besides, the code I dotest will certainly call the getter so it willbe tested.
TDD 中的规则是“测试所有可能破坏的东西”getter 能破坏吗？一般不会，所以我不费心去测试它。此外，我的代码做测试肯定会调用吸气所以它会被测试。
My personal rule is that I'll write a test for any function that makes a decision, or makes more than a trivial calculation. I won't write a test for i+1, but I probably will for if (i<0)...and definitely will for (-b + Math.sqrt(b*b - 4*a*c))/(2*a).
我个人的规则是，我将为任何做出决定或进行不重要计算的函数编写测试。我不会为 编写测试i+1，但我可能会if (i<0)...并且肯定会为(-b + Math.sqrt(b*b - 4*a*c))/(2*a).
BTW, the emphasis on POJO has a different reason behind it. We want the vast quantity of our code written into POJOs that don't depend on the environment they run in. For example, it's hard to test servlets, because they depend upon executing within a container. So we want the servlets to call POJOs that don't depend on their environment and are therefore easy to test.
顺便说一句，强调 POJO 背后有不同的原因。我们希望将大量代码写入不依赖于它们运行的环境的POJO 。例如，很难测试 servlet，因为它们依赖于在容器内执行。因此，我们希望 servlet 调用不依赖于其环境并因此易于测试的 POJO。
回答by Kevin Crowell
POJOs may also contain other functions, such as equals(), hashCode(), compareTo(), and various other functions. It may be useful to know that those functions are working correctly.
POJO 还可能包含其他函数，例如 equals()、hashCode()、compareTo() 和各种其他函数。了解这些功能是否正常工作可能很有用。
回答by David Carlson
I don't think there's a point to testing simple property getters and setters. The point of unit-testing is not to verify that your compiler works.
我认为测试简单的属性 getter 和 setter 没有意义。单元测试的重点不是验证您的编译器是否工作。
However, as soon as you add a conditional, null-check or other non-trivial behavior to your getters and setters (or other methods) I think it's appropriate to add unit tests.
但是，一旦您向 getter 和 setter（或其他方法）添加条件、空检查或其他重要行为，我认为添加单元测试是合适的。
回答by daanish.rumani
I think if the getters and setters have been created using an IDE then it should be fine. We have other things to put our code into. Obviously, you would test the POJO's for serialization/de-serialization.
我认为如果 getter 和 setter 是使用 IDE 创建的，那么应该没问题。我们还有其他东西可以放入我们的代码中。显然，您将测试 POJO 的序列化/反序列化。
回答by Jeff
My answer is that trivial getters and setters do not merit their own tests. If I add any code other than simple reads or writes, then I add tests.
我的回答是，琐碎的 getter 和 setter 不值得他们自己测试。如果我添加除简单读取或写入之外的任何代码，然后我添加测试。
Of course, this is all boilerplate, so you could easily write a script that generates unit tests for your getters and setters, if you think there's any value there. Certain IDEs may allow you to define a template that creates test cases with test methods filled in for this boilerplate code (I'm thinking of IntelliJ here, but Eclipse can probably handle it too, although I haven't done anything like this in either IDE).
当然，这都是样板文件，因此您可以轻松编写一个脚本，为您的 getter 和 setter 生成单元测试，如果您认为那里有任何价值的话。某些 IDE 可能允许您定义一个模板，该模板创建测试用例，并为该样板代码填充测试方法（我在这里考虑的是 IntelliJ，但 Eclipse 可能也可以处理它，尽管我在这两个方面都没有做过这样的事情IDE）。
回答by Theo
In my experience, creating unit tests for POJOs with only getters and setters, is just overkill. There are some exceptions, of course, if there is additional logic in the getter/setter like checking for null and doing something special, than I would create a unit test for that.
根据我的经验，仅使用 getter 和 setter 为 POJO 创建单元测试是过大的。当然，也有一些例外，如果 getter/setter 中有额外的逻辑，比如检查 null 和做一些特殊的事情，那么我会为此创建一个单元测试。
Also, if there's a bug in the POJO I'd create a unit test for it so we can prevent it from happening again.
此外，如果 POJO 中存在错误，我会为它创建一个单元测试，以便我们可以防止它再次发生。
回答by Brian Agnew
It's probably worth a simple test to make sure you've not written
可能值得进行一个简单的测试以确保您没有编写
public void setX(int x) {
x = x;
}
Although you should be coding to avoid that (by putting a finalmodifier on the method parameter, or similar). It also depends how you're generating your accessors, and if they could suffer from copy/paste errors etc (this will occur even in environments that try to enforce IDE usage - it just will).
尽管您应该编码以避免这种情况（通过final在方法参数上放置一个修饰符，或类似的）。它还取决于您如何生成访问器，以及它们是否会遭受复制/粘贴错误等（即使在尝试强制使用 IDE 的环境中也会发生这种情况 - 它只会发生）。
My main concern with classes containing lots of setters/getters, however, is what is the class doing? Objects should do stuff for you, rather than just hold and return data. If these are data entity objects then the setter/getter pattern may be correct. However the better pattern is to set the data in the object, and ask the object to do stuff with it (calculate your bank balance, launch the rocket etc.) rather than return the data and let you do it yourself!
但是，我对包含大量 setter/getter 的类的主要关注点是该类在做什么？对象应该为你做一些事情，而不仅仅是保存和返回数据。如果这些是数据实体对象，那么 setter/getter 模式可能是正确的。然而，更好的模式是在对象中设置数据，然后让对象用它做一些事情（计算你的银行余额，发射火箭等）而不是返回数据让你自己做！
回答by Nick Veys
Unit Test code you want to knowworks (for the situations tested of course). Don't unit test code you only want to be kind of sure works.
您想知道的单元测试代码有效（当然，对于测试的情况）。不要对您只想确保工作正常的代码进行单元测试。
I can't think of much I only want to be kind of sure about.
我想不出太多我只想确定一下。
回答by TofuBeer
I once spent two hours because of something like this:
我曾经因为这样的事情花了两个小时：
int getX()
{
return (x);
}
int getY()
{
return (x); // oops
}
Since it takes almost no time to write the tests for simple getters, I do it now out of habit.
由于为简单的 getter 编写测试几乎不需要时间，我现在出于习惯这样做。
回答by TofuBeer
I'm experimenting with cobatura for code coverage and just came across the same issue.
我正在尝试使用 cobatura 进行代码覆盖，但遇到了同样的问题。
It would be nice to have an annotation to add to the class which said don't include this class in code coverage. However it is possible to put your pojo's in a separate package and then exclude that package from the analysis.
有一个注释添加到类中会很好，它说不要在代码覆盖率中包含这个类。但是，可以将您的 pojo 放在一个单独的包中，然后从分析中排除该包。
See the documentation depending on your tool, it works with Ant, Maven or command line.
根据您的工具查看文档，它适用于 Ant、Maven 或命令行。
