很多开发者会说老项目就算了，如果新启动一个项目，我就会写单元测试了，Daniel认为这是一个“美好的梦想”，很多原因会打破它：
代码已经很烂了，又没办法下手了
UI不好测
认为这是QA的工作
写的单元测试找不到Bug
代码的外部依赖太多
代码稍作修改，测试也要一并修改，太麻烦了
究其根本原因，是开发者根本不会写单元测试!满足什么标准的测试才是单元测试呢?根据《修改代码的艺术》，需要访问数据库的测试不是单元测试，需要访问网络的测试不是单元测试，需要访问文件系统的测试不是单元测试……
为了更方便地进行单元测试，业务代码应避免以下情况：
存在太多条件逻辑
构造函数中做的事情太多
存在太多全局状态
混杂了太多无关的逻辑
存在太多静态方法
存在过多外部依赖
例如，在代码中存在硬编码，或者是直接创建了一个数据库连接，这种做法都是比较危险的，因为在测试时没有办法“偷梁换柱”。
想要写好单元测试，学会重构是很重要的，重构的过程类似于清理厨房，虽然和做饭没太大关系，但可以让您下次做饭更方便，心情更好。可以重构的地方包括，在待测试类与其依赖之间增加一层Test Fixture;将创建逻辑与业务逻辑分开等等。重构可以采取以下策略：
编写测试代码建立基本的防护网。在单元测试和功能测试之间要有取舍，如果单元测试实施成本很高，可以先加功能测试。
通过增加中间层来打破依赖，不是为了去掉依赖，而是为了后续的修改以及测试的便利。
将第一步中编写的功能测试换成单元测试。
最后，Daniel还为大家提了一些建议：
项目里的破窗要修好，别容忍别人加新的破窗，用测试将破窗保护起来。
当你离开一个地方的时候，要让它比你来的时候更整洁干净。(童子军军规)
不停地重构你的代码，每次走一小步。
随后有人提问，如何评估一个单元测试的质量，用代码行覆盖率是否可行。Daniel认为没必要去追求代码行覆盖率，真正要覆盖的是逻辑，而不是代码行。通过结对编程可以减少低质量的单元测试，人都喜欢改变，但没人喜欢被改变，不要强求结对编程，让他看到好处，尝到甜头，吸引他来做结对编程，没有人喜欢落后，比如50%的人在做结对了，剩下的人自然会想尝试。
当被问及单元测试是否是必须的时候，Daniel回答这并不是必要的，而是需要进行综合的衡量，比如你的竞争对手一周前推出了一个产品，你需要在一周内完成产品研发并上线，这时可以选择写或者不写单元测试，对于没有写过单元测试的人，一开始是需要上手的成本的。
转自:领测软件测试网[http://www.ltesting.net]
原文链接:http://www.ltesting.net/ceshi/ceshijishu/dycs/2012/0228/204222.html