应该仅对具有简单getter和setter的简单JavaBean进行单元测试吗？

带有getter和setter方法中的某些逻辑的Bean呢？

解决方案

如果不值得测试，就不值得编写。

这并不总是意味着我们应该编写测试。有时，这意味着我们应该删除代码。我们需要这些豆吗？他们实际上有什么重要的事情吗？如果需要它们，则应编写测试。如果不是这样，请删除代码并过着幸福的生活，因为我们无需维护。

我们只需要测试我们想要正常工作的内容即可。

(对不起，我偷了那句话的人)

我认为这是每个人对自己(自己)提出的问题之一。

但是考虑一下：访问器的内部逻辑现在简直太简单了，但是将来可能会改变，而且更重要的是，如果我们对方法进行了测试，则可以随意将其更改为所需的任何内容。因此，我们可以通过几个测试用例获得自由和信心。听起来不错，是吗？

如果这只是一个获取者/设置者，而没有更改任何值，那么我说没有必要进行测试。如果确实做到了逻辑，那么一些简单的单元测试将提供一定的安全性。

我们如何安全地重构未经测试的代码？如果我们没有测试，当bean pojo变化时会发生什么？我们要创建一个贫血域模型吗？

我们应该测试具有一定意义的事物。 Getter和Setter通常不包含任何逻辑，只是由于缺少属性而仅在Java中使用。我认为测试它们就像在每次评估" a.x"时检查Java是否都返回一个值一样愚蠢。

如果访问器确实有逻辑，则由我们决定阈值。如果团队很懒惰。最好测试所有逻辑。如果比较严格，最好找到一个不会使我们编写过多样板测试的比率。

我们不应该编写以下测试：

• 测试语言或者IDE(即自动生成的getter和setter)
• 为测试工具增加任何价值，并打消我们进行单元测试的热情

这同样适用于仅具有属性的.NET对象(有时称为" Info"对象)。

在理想的情况下，我们将拥有100％的测试覆盖率，但实际上这不会发生。因此，将客户的钱花在可以增加最大收益的地方，即为具有复杂状态和行为的类编写测试。

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

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

• 这段代码是相对于整体功能导入的吗？
• 这段代码可能会在此应用程序的生命周期内发生变化吗？

如果两个问题都回答"是"，则需要进行单元测试。

在我看来，编写单元测试的目的是测试被测试单元的业务逻辑。因此，如果没有业务逻辑(例如，当getter简单地返回一个值或者setter对其进行设置时)，那么编写测试就毫无意义。但是，如果存在某种逻辑(getter在返回数据之前以某种方式更改数据)，则可以，我们应该进行单元测试。
通常，我认为不应为不包含任何业务逻辑的bean编写测试。

如果它具有一个外部接口并包含一个人编写的代码(而不是由IDE或者编译器自动生成)，那么绝对应该对其进行测试。

如果这两个条件中的一个或者两个都不成立，那就是一个灰色地带，而更多地归结为"皮带和吊带"式的问题，即我们有多需要谨慎。

另一个经验法则(类似于其他人所说的)是"测试任何可能破坏的东西"。对我来说，它不包括自动生成的getter和setter，但包括包含某些逻辑的手写的。