5. 培养开发人员良好的编程习惯 - 优秀的程序员只是因为习惯。例如没写一个函数前都写测试代码，遵循编程规范，清晰的代码逻辑，边界条件的判断和异常处理，事件日志的清晰记录习惯，析构函数，Dispose方法的实现，函数和类的独立性和单一职责，实现方法的效率等，都和程序员的习惯和专业素质有关。良好的编程习惯能尽量保证在一开始写程序时就避免bug的发生。（Careful programmers test early and test often.）。而对开发人员自身的职业生涯来说，良好的编程习惯也是大有帮助的。编写单元测试是一个专业程序员必须做的。

　　6. 构建自动化测试环境 - 单元测试用例需要一个自动化执行的环境，即一个能够由外部条件触发而自动运行。单元测试用例本身要能够自动化的进行，不能每次运行之前需要先配置好环境之类，也即能满足回归测试的要求。我们使用CruiseControl.NET这个持续集成工具来进行自动化的配置，具体可参见http://ccnetlive.thoughtworks.com/。采用一个定时的方式来发动集成请求，我们把这个时间设置在半夜，具体做的事情如下：先去 SVN上取出最新的源代码和测试代码，然后编译，最后使用NUnit运行生成的测试dll。

　　良好的单元测试策略给我们增强了对程序的信心,减少了bug的产生及bug的潜伏期。降低修改bug的代价。单元测试不会是项目开发周期的某一个生命周期，它贯穿于项目的整个生命周期，是一个非常重要的日常开发活动。

　　当然，公司的budget是有限的，时间资源是有限的，开发人员的时间是有限的，不能做到每个函数每条分支路径都覆盖测试到，所以当我们说单元测试是“必须”的时候，最好还是先看看表，数数人头，再摸摸自己的钱包，确定一下哪些是“必须的”，哪些不是“必须的”，掌握好测试的切入点和目标的粒度，在列表里划出优先级，同时标出不可获缺的测试，平衡的艺术难就难在把握分寸。我认为单元测试的必要性，很多时候来自于开发者脑中对该单元的不确定性，增强自己对这个函数的信心，保证自己代码的质量，减少后期出错的概率，把bug消灭在摇篮中，同时也减少自己后期代码交付以后的担忧和恐惧。

　　有些人会把测试和TDD联系起来，其实TDD是测试驱动开发，重点是“驱动”，不要搞混淆了。你们用不用TDD来驱动那是仁者见仁智者见智的事情，本文所说的单元测试，和TDD没有直接联系。不管你是否TDD，都可以做单元测试。

　　最后要说的是，流程配合工具，如果用的好，组织内部的软件构件水平可以上升一个台阶，反之，为了UT而UT，把它变成哗众取宠、华而不实的绣花枕头，走形式的流程比没有这个流程还要糟糕。适合的才是最好的。工具好还要用的好，流程好还要执行的好！