Java 单元测试的意义是什么？

我最近加入了一个大量使用单元测试的团队。没有人能向我解释为什么这种形式的测试如此重要，但他们把它当作法律对待

---

我知道自动化测试的想法是为了防止回归，但我不认为这会是一个问题。模块化的、面向对象的、简洁的、注释良好的代码在回归方面没有问题。如果您第一次构建正确，并且为将来不可避免的特性崩溃而设计，您将永远不需要测试

而且，这不是优雅的错误处理和日志记录应该完成的吗？既然您可以确保所有外部依赖项都先仔细检查它们的可用性，为什么还要花上几周的时间来散列断言语句和单元测试呢

我是否傲慢地得出这样的结论：单元测试是“坏”代码库的支柱，这些代码库有缺陷，构建得很差

这是一个严肃的问题。我在任何地方都找不到好的答案，如果我质疑自动化测试的目的，我问的每个人似乎都认为我是个巨魔

---

编辑：谢谢你的回答，我想我现在明白了。我看到一些人投票赞成删除，但我要感谢那些回答的人；真的很有用

没有人是完美的——你最终会犯错误。单元测试旨在捕获并精确定位错误的位置，以便：

• 增加对所编写代码正确性的信心
• 增加对重构正确性的信心
• 使跟踪在测试阶段引入错误的位置变得更加简单

错误处理和日志记录仅在触发错误时有用单元测试是在测试中而不是在生产中触发bug的原因

---

考虑下面… 您有一个包含3个不同部分的软件，每个部分有2个不同的选项

     A      C      E
    / \    / \    / \
in-<   >--<   >--<   >-out
    \ /    \ /    \ /
     B      D      F

ace
/ \    / \    / \
输入-<>-->-<>-输出
\ /    \ /    \ /
B D F

您可以通过手动输入并检查输出来测试这一点-首先输入一些触发A、C、E的输入；然后你会加入一些A，C，F，等等，直到你覆盖了B，d，F的所有内容

但请记住，B、D和F都有各自需要测试的参数和流，我们会说每个参数和流可能有10种变化。因此，您至少需要检查

10*10*10=1000

不同的输入，仅针对A、C、E情况。这6个组件中有8种不同的可能流，因此需要检查8000不同的输入组合，以确保命中所有不同的可能输入

另一方面，您可以进行单元测试。如果您清楚地定义了每个组件的单元边界，那么您可以为A编写10个单元测试，为B编写10个单元测试，以此类推，测试这些边界。这将为组件提供总共60个单元测试，再加上一些（比如每个流5个，那么40个）集成测试，以确保所有组件正确地连接在一起。总共有100个测试有效地实现了相同的功能覆盖率

---

通过使用单元测试，您已经将获得同等覆盖率所需的测试量减少了大约80x！这是一个相对简单的系统。现在考虑更复杂的软件，其中组件的数量几乎肯定大于6，并且这些组件处理的可能情况的数量几乎肯定大于10。您从单元测试而不仅仅是集成测试中获得的节省不断增加。

当您第一次开始编写代码时，它可能看起来非常简单，不需要自动测试

但随着时间的推移，您的代码会增长，需求会发生变化，团队也会发生变化。自动化测试的需求也将增长。如果没有自动化测试，开发人员将害怕重构代码——特别是如果他们不是编写代码的人。即使使用精心设计的代码，添加新特性也会破坏现有特性。但代码并不总是经过精心设计的。实际上，你可能需要做出妥协。由于各种原因，您的一些代码将不会像您希望的那样干净和可维护。当您意识到需要自动测试时，可能无法添加它们，因为您的某些类可能很难测试。要添加第一个自动化测试，您可能必须首先重写或重构大量代码

---

如果您从一开始就有自动测试，这将确保您将代码设计为可自动测试的。

简短回答：是的，您很傲慢。）

假设您真的是完美的，那么您的代码在编写时不仅是正确的、完美的，而且还考虑了所有未来的需求

现在。。。。您如何知道您的代码是完美和正确的？ 你需要测试一下。如果它没有经过测试，你就不能相信它能工作

这不仅仅是回归（因为这意味着代码过去是可以工作的。如果它从来没有工作过呢？当它第一次被编写时是有缺陷的）

我知道自动化测试的想法是为了防止回归，但我不认为这会是一个问题。模块化的、面向对象的、简洁的、注释良好的代码在回归方面没有问题

谁告诉你的？那个人应该被鞭打。 面向对象的代码和其他代码一样容易出错。它没有什么神奇之处，它不是银弹。在一天结束的时候，每当你改变一段代码，你都有可能在某个地方破坏某些东西。根据所讨论的代码，可能性可能更大或更小，