软件开发中单元测试的作用？
--------------
其实以前一直不是很理解单元测试的作用，一直认为是做某个方法的测试用，后来发现其他同事的讲解，某个系统做大量的单元测试业务及单元测试用例，以便在软件发布编译的时候确保无论方法怎么改动 方法本身都是正确的，这样确保不至于代码的修改影响到版本BUG，请问是这样理解么或者说大家都是这样做的么？
------解决思路----------------------
单元测试只是一个工具，不要过度解读“单元”的概念。就像过去，有的人用尺子去衡量程序模块的长度、或者用代码行数去衡量模块的大小，这都是不对的做法。
单元测试工具如果只是被人用来跟在开发完的代码的屁股后头去写单元测试，其实很快你就会看到这些人就懒得些单元测试了，或者为了“覆盖率”指标而作假了。因为人之常情，谁会在刚辛苦地实现一个功能时，立刻就去挑自己的毛病呢？而某些团队甚至扯什么“个人负责个人的代码”，这就更加让单元测试束之高阁，被阉割。
单元测试应该是一个产品经理、项目经理的核心技术和“秘密武器”。如果要安排每一小时的开发工作，在开发计划经过了评审并确定下来之后，项目经理就可以自己亲自（或者让自己最信赖的人）编写单元测试程序了。每当他想知道一下开发进度，把版本管理系统中的代码check out 出来，跑一下单元测试，就知道进度了。
而对于一般的开发人员，在将代码 check in 之前，必须跑一下（对全公司公开的）单元测试，至少是最近3天的单元测试。如果可能还应该跑一下自己私人的单元测试。然后再check in。
对于质量保证和测试人员，凡是以前发现过的问题，都应该落实到单元测试上。bug反馈必须变成可执行的代码，而不是停留在口头或者书面上。如果不会把bug问题变为可执行的代码，就说明这个公司的测试人员都是纯手工的，没有编程技术。
而对于产品发布人员，显然在发布产品之前，起码地知道要干什么吧？！
上面只是最基本、最低级的描述，用来描述单元测试的作用。没有这些，如何保证为千变万化的产品研发过程编织一个安全网呢？没有这些，那么你的公司不就是一个手工小作坊嘛！
------解决思路----------------------
在计算机编程中，单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定。
每个理想的测试案例独立于其它案例；为测试时隔离模块，经常使用stubs、mock[1]或fake等测试马甲程序。单元测试通常由软件开发人员编写，用于确保他们所写的代码符合软件需求和遵循开发目标。它的实施方式可以是非常手动的（通过纸笔），或者是做成构建自动化的一部分。
------解决思路----------------------
这个也看你做的东西的生命周期，如果生命很短，比如一些很快做好，不怎么维护的项目，单元测试没什么必要。生命周期越长，单元测试越能体现其价值。
主要作用一是避免开发时无意间破坏已有功能，尤其是他人开发的功能；二是为重构打下良好基础，如果没有单元测试而产品已经上线，根本就不敢重构，那么代码的可维护性就会越来越差，新功能的开发也会越来越困难，最终导致无法继续；三是相当于代码使用说明，比如自己过一阵忘记了，或者新来的人，直接看代码容易陷入细节，而看单元测试更容易理解功能。
另外，还能检查单元测试的覆盖率，不过这个很容易导致故意为了覆盖而测试，就和为了考试而学习一样，如果开发人员没有足够的水平会弊大于利。还有 TDD，也就是先写接口和单元测试，后写实现。不过这个更不是一般水平的开发能做到的，没有一个精英团队就不用考虑了。
学会写单元测试很简单，然而培养出写可测试代码的习惯很困难，后者才是最最重要的。这里需要一种意识的转变，也是软件设计能力的体现。可测试的代码意味着良好的隔离，比如最终实现同样功能的 webforms 和 mvc，前者不可测试，而后者可测试。对于个人来说，如果想在设计能力上提高，逼自己写单元测试也是个不错的办法，慢慢让自己习惯于写可测试的代码。