域对象和简单JavaBeans应该进行单元测试吗？

Question

只有简单的getter和setter的简单JavaBeans应该进行单元测试吗？

Beans在getter和setter中有一些逻辑怎么样？

Answer 1

你不应该写下以下的测试：

• 测试语言或IDE（即自动生成的getter和setter）
• 不会为您的测试工具增加任何价值并扼杀您对单元测试的热情

同样适用于仅具有属性的.NET对象（有时称为“Info”对象）。

在一个理想的世界中，你将有100％的测试覆盖率，但实际上这不会发生。因此，花费客户的钱来增加最大的收益，即为具有复杂状态和行为的类编写测试。

如果您的JavaBean变得更有趣，您当然可以在以后添加测试用例。与单元测试/ TDD相关的一个常见问题是错误地认为一切都必须是第一次完美。

Answer 2

如果不值得测试，那就不值得写了。

这并不总是意味着你应该写测试。有时它意味着你应该删除代码。你需要这些豆子吗？他们真的做了什么重要的事吗？如果您需要它们，您应该编写测试。如果没有，删除代码并过上更幸福的生活，因为你知道自己维护的次数较少。

Answer 3

我认为这是每个人都问自己（自己）的问题之一。

但请考虑一下：访问器的内部逻辑现在很简单，但它可能会在将来发生变化，而且 - 更重要的是 - 如果你有测试，你可以自由地将它改为你想要的任何东西。方法。因此，您可以通过几个测试用例获得自由和自信。听起来很划算，是吗？

Answer 4

如何安全地重构未经测试的代码？如果没有测试，当你的bean pojo改变时会发生什么？您是在创建Anemic Domain Model吗？

Answer 5

另一个经验法则（类似于其他人所说的）是“测试任何可能破坏的东西”。对我来说，不包括自动生成的getter和setter，但包括手写的包含一些逻辑的。* / p>

Answer 6

您只需要测试您想要正常工作的内容。

（对不起我偷了那句话的人）

Answer 7

你应该测试有意义的东西。 getter和setter通常不包含任何逻辑，仅在Java中用于缺少属性。我认为测试它们就像检查Java每次评估“a.x”时确实返回一个值一样愚蠢。

如果访问者确实有逻辑，则由您决定阈值。如果你的团队很懒散。最好测试所有逻辑。如果它更有纪律，最好找一个不会让你写太多样板测试的比例。

Answer 8

如果它只是一个getter / setter而没有改变任何值，我会说没有必要进行测试。如果它确实做了一些逻辑，一些简单的单元测试将提供一些安全性。

Answer 9

与Maxim已经说过：测试不会为您的应用程序添加额外的功能，但可以让您更自信地进行更改。为了确定哪些类/方法可以进行单元测试，我总是问自己两个问题：

• 是根据整体功能导入的这段代码吗？
• 这段代码可能会在本申请的有效期内发生变化吗？

如果两个问题的答案都是肯定的，则需要进行单元测试。

Answer 10

在我看来，编写单元测试的目的是测试测试单元的业务逻辑。因此，如果没有业务逻辑（例如，当getter只返回一个值或者setter设置它时），则编写测试没有意义。但是，如果有一些逻辑（getter在返回之前以某种方式更改数据）那么是的，你应该进行单元测试。 作为一般规则，我认为不应该为不包含任何业务逻辑的bean编写测试。

Answer 11

如果它有一个外部接口并且包含一个人写的代码（而不是由IDE或编译器自动生成），那么它肯定应该被测试。

如果这些条件中的一个或两个都不成立，那么它就是一个灰色区域，并且更多的是“腰带和吊带”类型的问题，即你觉得需要多么小心。