我公司的人员认为单元测试是一项额外的工作，与现有的功能测试相比，它的优势更少。单元和集成测试值得吗？请注意一个大型的现有代码库，它没有考虑到测试而设计。
答案 0 :(得分：12)
大多数人都不知道自动化单元测试的用途：
因此，如果这些原因中的任何一个为您带来好处，那么自动化单元测试就适合您。如果没有，那就不要浪费你的时间。
答案 1 :(得分：9)
（我假设您正在使用“功能测试”来表示涉及整个系统或应用程序启动并运行的测试。）
我会在编写时单元测试 new 功能，原因有三：
（这包括错误修复，如Epaga所建议的那样。）
我强烈建议Michael Feathers'"Working Effectively with Legacy Code"向您提供有关如何开始单元测试不是为其设计的代码库的提示。
答案 2 :(得分：3)
这取决于您的功能测试是自动化还是手动完成。如果是后者，则任何类型的自动化测试套件都是有用的，因为运行这些单元/集成测试的成本远低于运行手动功能测试。您可以在那里显示真实的ROI。我建议从编写一些集成测试开始，如果将来时间/预算允许，那么请看一下单元测试。
答案 3 :(得分：3)
追溯性地为遗留代码编写单元测试通常不值得。坚持功能测试，并自动化。
然后，我们所做的是指导任何错误修复（或新功能）必须伴随单元测试，至少测试修复。这样你就可以让项目至少朝着正确的方向发展。
我必须同意Jon Skeet（我怎么能不这样做？）推荐“Working Effectively With Legacy Code”，这真的是一个有用的脱脂/阅读。
答案 4 :(得分：3)
碰巧，我昨晚在这个主题上看了a paper。作者比较了微软和IBM四个小组的项目，事后对比的是，使用单元测试和功能测试的项目以及仅使用功能测试的项目。引用作者：
“案例研究的结果 表示预览版本 四种产品的缺陷密度 相对减少40％至90％ 对于没有使用的类似项目 TDD实践。主观上， 团队经历了15％至35％的增长 在最初的开发时间之后 采用TDD。“
这表明在为项目添加新功能时，确实值得进行单元测试。
答案 5 :(得分：1)
是的，他们是值得的，因为我开始对代码进行单元测试，所以我现在编码速度更快。我花了更少的时间修复错误，花更多的时间考虑我的代码应该做什么。
答案 6 :(得分：1)
我买了一个应用程序来咨询FAT（测试），包括21,000行切换语句。在一个案例陈述中，大多数功能单元都是几十到几百行。该应用程序有几种变体，因此交换机有很多#ifdef部分。
它不是为单元测试而设计的 - 它根本没有考虑因素。
（它的设计意义上有一个明确的，易于理解的体系结构 - malloc一个结构，向主循环发送一个用户消息，其指针指向结构作为lparam，然后在处理消息时释放它。但形式没有遵循功能，这是良好设计的核心原则。）
将单元测试添加到新功能意味着与模式的重大突破;或者您需要将代码放在除大开关之外的其他位置，并将变体选择机制的复杂性加倍，或者使用大量脚手架将消息放入队列以触发新功能。
因此，尽管单元测试新功能当然是可取的，但如果系统尚未得到很好的考虑，那么它并不总是可行的。要么重构系统以允许进行单元测试，要么进行大量测试，或者最终对代码进行基准测试并将其剪切并粘贴到现有框架中，并且单元测试代码的副本不是单元测试代码。< / p>
答案 7 :(得分：1)
当你想知道某事时，你会进行测试。如果您知道您的产品（系统，单元，服务，组件......）将起作用，则无需进行测试。如果你不确定它是否会起作用，你可能会对它有一些疑问。这些问题是否值得回答是风险和优先事项。
如果您确定您的产品能够正常运行，并且您对此产品没有任何疑问，那么还有一个问题值得一提：为什么我没有任何问题？
--- Michael B。
答案 8 :(得分：1)
单元测试确实是额外的工作，但从长远来看它会得到回报。这里有 优于集成测试的优势：
两者之间显然存在一些重叠，但它们是互补的，因为它们都具有优势。
现在，就像任何软件工程过程一样，必须根据测试进行测试 对项目的需求。
拥有大量的遗留代码库，遗留在未经单元测试的意义上，我愿意 建议将单元测试限制为添加到代码中的新功能 单元测试很难介绍。在这方面， 我只能第二次（第三次）推荐“工作 有效地使用遗留代码“书来帮助在现有的单元中进行单元测试 代码库。