【发布时间】：2009-02-17 08:54:33
【问题描述】：
我公司的人认为单元测试是一项额外的工作，与现有的功能测试相比，它提供的好处更少。单元和集成测试值得吗？请注意在设计时并未考虑测试的大型现有代码库。
【问题讨论】：
标签： unit-testing testing scrum integration-testing functional-testing
【发布时间】：2009-02-17 08:54:33
【问题描述】：
大多数人不知道自动化单元测试的用途：
- 尝试新技术
- 记录如何使用部分代码
- 确保死虫不死
- 允许您重构代码
- 允许您更改代码的任何主要部分
- 创建一个较低的水印，低于该水印，您的产品质量不可能下降
- 提高开发速度，因为现在，您知道某些东西有效（而不是希望它在客户报告错误之前有效）。
因此，如果这些原因中的任何一个为您带来好处，那么自动化单元测试就是您的不二之选。如果没有，那就不要浪费你的时间了。
【讨论】：
（我假设您使用“功能测试”来表示涉及整个系统或应用程序启动并运行的测试。）
我会在编写时对 新 功能进行单元测试，原因有以下三个：
- 它可以帮助我更快地编写工作代码。 “单元测试失败，修复代码，单元测试通过”的周转时间通常比“功能测试失败，修复代码，功能测试通过”短很多。
- 它帮助我以更简洁的方式设计代码
- 它可以帮助我理解我的代码以及在我来维护它时它意味着什么。如果我做出改变，它会让我更有信心，我没有破坏任何东西。
（这包括 Epaga 建议的错误修复。）
我强烈推荐 Michael Feathers 的"Working Effectively with Legacy Code" 为您提供有关如何开始对不是为它设计的代码库进行单元测试的提示。
【讨论】：
-
但是“集成测试”呢？我想对相同的代码进行单元测试、集成测试和功能测试真的没有意义......当功能测试被编写为开发人员测试（使用 Java 中的 JUnit 或 TestNG）时，与集成测试有什么区别?
-
@Rogerio：这是灰色阴影。集成测试可能会将系统的一些部分而不是整个系统整合在一起，并且可能会使用类似于内存数据存储的东西而不是真实的。
这取决于您的功能测试是自动完成还是手动完成。如果是后者，那么任何类型的自动化测试套件都是有用的，因为运行这些单元/集成测试的成本远低于运行手动功能测试。您可以在那里显示真实的投资回报率。我建议从编写一些集成测试开始，如果将来时间/预算允许，那么再看看单元测试。
【讨论】：
-
我们有自动化的功能测试，我们也做手动测试。尽管展望未来，我们越来越依赖自动化测试。这些仍然不是那么快〜20分钟来运行基础知识。
-
我向您保证，这比释放大量测试人员来对抗您的应用程序并等待他们整理测试结果要快得多。 :)
为遗留代码追溯编写单元测试通常是不值得的。坚持功能测试，并将它们自动化。
那么我们所做的就是制定任何错误修复（或新功能）必须伴随单元测试至少测试修复的指导方针。这样，您至少可以让项目朝着正确的方向发展。
我必须同意 Jon Skeet（我怎么可能不同意？）推荐“Working Effectively With Legacy Code”，这确实是一个很有帮助的略读/阅读。
【讨论】：
碰巧，我昨晚阅读了a paper 就这个主题。作者比较了 Microsoft 和 IBM 四个小组内的项目，事后对比了同时使用单元测试和功能测试的项目以及单独使用功能测试的项目。引用作者的话：
"案例研究的结果 表示预览版 四种产品的缺陷密度 相对下降了 40% 到 90% 对于没有使用的类似项目 TDD 实践。主观上， 团队经历了 15% 到 35% 的增长 在最初的开发时间之后 采用 TDD。”
这表明当您向项目中添加新功能时，进行单元测试当然是值得的。
【讨论】：
-
但是只有如果你想走得更快并且有更少的错误......
-
我认为速度更快，错误更少，这对我的公司来说是一件好事 :) 更不用说我们是一家 MS 商店，所以他们写的任何东西都一定有一定的分量。
-
是不是速度变慢了，bug 也少了。我读到“初始开发时间增加 15% 到 35%”的意思是 TDD 人员认为这需要更长的时间。
-
@WW：+1。另外，为什么论文将 15-35% 的增长描述为“主观的”？他们没有衡量开发时间吗？
是的，它们是值得的，自从我开始对我的代码进行单元测试后，我现在的编码速度更快了。我花更少的时间修复错误，而花更多的时间思考我的代码应该做什么。
【讨论】：
我被买来咨询 FAT（测试）测试的一个应用程序，它包含一个 21,000 行的 switch 语句。大多数功能单元在案例语句中只有几十到几百行。该应用程序是在几个变体中构建的，因此开关中有许多#ifdef 部分。
它不是为单元测试而设计的——根本没有考虑到它。
( 它的设计是为了有一个明确的、易于理解的体系结构 - malloc 一个结构，向主循环发送一条用户消息，其中指向该结构的指针作为 lparam，然后在处理消息时释放它。但是形式不跟随功能，这是好的设计的核心原则。）
将单元测试添加到新功能将意味着与模式的重大突破；要么您需要将代码放在大开关以外的地方，并使变体选择机制的复杂性加倍，要么制作大量脚手架将消息放入队列中以触发新功能。
因此，尽管对新功能进行单元测试肯定是可取的，但如果系统尚未充分考虑因素，它并不总是可行的。要么有大量工作来重构系统以允许单元测试，要么您最终对代码进行基准测试并将其剪切并粘贴到现有框架中 - 单元测试代码的副本不是单元测试代码。
【讨论】：
当您想了解某事时，您会进行测试。如果您知道您的产品（系统、单元、服务、组件……）可以正常工作，则无需对其进行测试。如果您不确定它是否会起作用，您可能对此有一些疑问。这些问题是否值得回答是风险和优先事项的问题。
如果您确定您的产品可以工作，并且您对此没有任何疑问，那么还有一个问题值得问：为什么我没有任何问题？
---迈克尔 B.
【讨论】：
单元测试确实是额外的工作，但从长远来看它是有回报的。这里有 与集成测试相比的优势：
- 您将获得一个回归套件，它在重构时充当安全网 - 集成测试也是如此，尽管很难说是否 测试涵盖了一段代码。
- 单元测试在修改代码时会立即提供反馈 - 而这 反馈可以很准确，指向异常所在的方法 是。
- 这些测试运行起来很便宜：它们运行得非常快（通常几秒钟）， 无需任何安装或部署，只需编译和测试。因此它们可以经常运行。
- 一旦发现问题，很容易添加新测试来重现问题， 它增加了回归套件，或者回答一个问题（“如果 此函数不是使用空参数调用的...")。
两者之间显然有一些重叠，但它们是互补的，因为它们都具有优势。
现在，就像任何软件工程过程一样，测试必须根据 满足项目需求。
拥有庞大的遗留代码库，即未经过单元测试的遗留代码，我会 建议将单元测试限制为添加到代码中的新功能 单元测试可能很难引入。在这方面， 我只能第二（第三？）“工作”的建议 有效地使用遗留代码”一书，以帮助将单元测试引入现有的 代码库。
【讨论】：