软件开发中单元测试的作用？

[findshine]

软件开发中单元测试的作用？
--------------
其实以前一直不是很理解单元测试的作用，一直认为是做某个方法的测试用，后来发现其他同事的讲解，某个系统做大量的单元测试业务及单元测试用例，以便在软件发布编译的时候确保无论方法怎么改动 方法本身都是正确的，这样确保不至于代码的修改影响到版本BUG，请问是这样理解么或者说大家都是这样做的么？

[以专业开发人员为伍]

不论是 asp.net webform、wpf、silverlight、typescript（非微软的我就不说了），不论是控制台还是windows service程序，都是可以编写单元测试的。显然当你关心一个 html 中是否某些标签有没有规范地“关闭”，或者关心程序模拟某个场景时某个事件的响应时间是不是在500毫秒之内，或者关心远程服务器集群是否总有n个有响应，或者关心某个插件一定是兼容某个标准的，等等非功能性需求，也一样可以使用单元测试。 只不过不同平台稍有差别。比如说对于以前的 asp.net webform 来说，你需要在向客户端注册 this.ClientScript.GetPostBackEventReference(this.Button1, string.Empty) 来自动模拟了用户点击之类的操作之后，你的测试程序能够继续执行下面的预先设计好的后边的代码。 有些人问“在asp.net程序中，我怎样能够在计算运行过程中向浏览器端用户提问，等用户回复后再根据用户选择而继续计算？”。如果你不会这个asp.net编程，那么自然就不能写单元测试。 对于像 silverlight、wpf 之类的广泛和使用异步操作机制的程序也是一样，它们的测试用例也是一个“组件、插件”，那么测试引擎捕获到测试组件跑出了一个 Completed 事件时才自动加载下一个测试用例，而其它时间根本不监督也不参与测试程序。而不是像简单的控制台测试引擎那样简单地调用一个 Fun<T>。就是这么点差别。 说 UI 不能测试，这是一个误区。其实也很容易测试，没有什么难度。如果你不敢写UI 方面的测试，那么你也就只能见到少量的单元测试了。自然，对进度的把握，对代码改动的保护，也就少了大半。所以要想进行单元测试，一定要突破“UI不能测试”这种心理障碍。 单元测试是一个重要的工具，其作用非常广泛。不是停在玩儿“单元测试”这个概念上。

[郑州高新区WPF小王子]

从来没有单元测试过。

[娃都会打酱油了]

本质就是保证方法被修改后，结果还符合预期要求，你的理解是对的，至少我的理解是跟你一样的，由此展开的自动化测试化什么的还是脱离不了这个中心思想

[阿布Guu]

单元，相当于零件，每个零件都确认无误，组装起来的部件进而整个机体的质量才有保证。

[以专业开发人员为伍]

单元测试只是一个工具，不要过度解读“单元”的概念。就像过去，有的人用尺子去衡量程序模块的长度、或者用代码行数去衡量模块的大小，这都是不对的做法。 单元测试工具如果只是被人用来跟在开发完的代码的屁股后头去写单元测试，其实很快你就会看到这些人就懒得些单元测试了，或者为了“覆盖率”指标而作假了。因为人之常情，谁会在刚辛苦地实现一个功能时，立刻就去挑自己的毛病呢？而某些团队甚至扯什么“个人负责个人的代码”，这就更加让单元测试束之高阁，被阉割。 单元测试应该是一个产品经理、项目经理的核心技术和“秘密武器”。如果要安排每一小时的开发工作，在开发计划经过了评审并确定下来之后，项目经理就可以自己亲自（或者让自己最信赖的人）编写单元测试程序了。每当他想知道一下开发进度，把版本管理系统中的代码check out 出来，跑一下单元测试，就知道进度了。 而对于一般的开发人员，在将代码 check in 之前，必须跑一下（对全公司公开的）单元测试，至少是最近3天的单元测试。如果可能还应该跑一下自己私人的单元测试。然后再check in。 对于质量保证和测试人员，凡是以前发现过的问题，都应该落实到单元测试上。bug反馈必须变成可执行的代码，而不是停留在口头或者书面上。如果不会把bug问题变为可执行的代码，就说明这个公司的测试人员都是纯手工的，没有编程技术。 而对于产品发布人员，显然在发布产品之前，起码地知道要干什么吧？！ 上面只是最基本、最低级的描述，用来描述单元测试的作用。没有这些，如何保证为千变万化的产品研发过程编织一个安全网呢？没有这些，那么你的公司不就是一个手工小作坊嘛！

[以专业开发人员为伍]

我可以告诉你一个事实，编写测试代码需要真正开发人员的头脑——逻辑头脑。我们看一个开发人员懂不懂技术，不是看他会不会实现某个功能，而是看他的测试代码写的怎么样，然后再看他是否能让测试程序都跑过。许多“混的”都会八仙过海地用各种办法去实现功能需求，甚至有些人故意把自己弄伤了、休息3天，然后花钱请人替自己写一大堆代码自己照着修改，然后再来上班时说是自己想出的解决方案。但是测试代码其实很简单、很少的3、4行代码就行了，这就不容易造假，也不耽误阅读时间，可以一下子就看出一个人的思路。

[以专业开发人员为伍]

对于程序员遇到了bug而需要调试来说，假设有比较合理的单元测试，那么他就需要很短的调试时间。大多数情况下，甚至不需要过度调试。假设你10分钟还不明白程序的逻辑，就可以停止调试，而转而写1、2个单元测试。然后让单元测试先通过，再回来跑之前的那个bug（已经被写为一个可执行代码从而可以重现bug了），往往就能立刻将解决思路确定再很狭窄的逻辑范围内，而不用怎样去担心造成其它质量问题。 单元测试是“勇气”的保证。没有勇气的人，往往都是不知道单元测试的作用的。（当然，有勇气的人也可能是个骗子，而不是靠高强度的自动化技术来保证的）

[nomasp]

在计算机编程中，单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。 通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定。 每个理想的测试案例独立于其它案例；为测试时隔离模块，经常使用stubs、mock[1]或fake等测试马甲程序。单元测试通常由软件开发人员编写，用于确保他们所写的代码符合软件需求和遵循开发目标。它的实施方式可以是非常手动的（通过纸笔），或者是做成构建自动化的一部分。

[nomasp]

单元测试是极限编程的基础，依赖于自动化的单元测试框架。自动化的单元测试框架可以来源于第三方，如xUnit，也可以由开发组自己创建。 极限编程创建单元测试用于测试驱动开发。首先，开发人员编写单元测试用于展示软件需求或者软件缺陷。因为需求尚未实现或者现有代码中存在软件缺陷，这些测试会失败。然后，开发人员遵循测试要求编写最简单的代码去满足它，直到测试得以通过。 系统中大多数代码都经过单元测试，但并非所有代码路径都必需单元测试。极限编程强调“测试所有可能中断”的策略，而传统方法是“测试所有执行路径”。这使得极限编程开发人员比传统开发少写单元测试，但这并不是问题。不争的事实是传统方法很少完全遵循完整地测试所有执行路径的要求。[来源请求]极限编程相互地认识到测试很少能完备（因为完备测试通常需要昂贵的代价和时间消耗，意味着不经济），提供了如何有效地将有限资源集中投入可花费的代价到问题关键的导引。 至关重要的，测试代码应视为第一个项目成品，与实现代码维持同等级别的质量要求，没有重复。开发人员在提交程序单元代码时一并提交单元测试代码到代码库。彻底的极限编程单元测试代码提供上述单元测试的收益，如简化和更可信的程序开发和重构、简化代码集成、精确的文档和模块化的设计。而且，单元测试经常作为复合测试的一种形式被运行。

[枕戈待旦勇往直前]

周末帮顶。简言之单元测试是整体测试的基础，相当于零件之于整体

[huaikong666]

写完代码不自测？

[qq_31624711]

[qq_31626247]

[qq_31627155]

………无语………………

[hwyqy]

确实是用来实现自动测试，省得改点东西就要手工测一遍

[xxm712]

保证代码被修改后不影响现有的结果

[江南小鱼]

好吧，哥是来看评论的。

[_lee_chong]

不会全覆盖的去做单元测试。。。。我的程序功能是否可用大多和硬件设备，操作系统有非常高的关联，大多处理性函数都依赖一系列sdk或系统相关功能的初始化及配置代码，还有一堆全局变量，未知的函数指针。。。你要怎么针对每个函数做测试。。。 大多测试都是硬件及操作系统的兼容性测试，必须得整个模块的测试～～ 所以，别去纠结必须要单元测试，从实际出发，恐怕在藕合度不高的程序里才可行吧～ 至于说“版本bug”。。。我们每次都是全覆盖测试。。。

[findshine]

谢谢各位大神指教

[郗晓勇]

http://lvvbbe.com/questions/8148012/is-unit-testing-worth-the-effort