以前发布开源项目时被国外的网友一阵鄙视，之后在自己的一些小项目中陆陆续续的有写一些单元测试。你一旦真正接受单元测试，并实行起来还是很容易体会到单元测试的优点的。只是尽管单元测试有很多优点，在国内的环境下写单元测试的公司依旧不多。
单元测试的好不是立竿见影，需要时间的累计。在最求“速成”的环境下，单元测试没法推行也是显而易见的。
单元测试的问题

• 单元测试并是立即见效的
  单元测试代码的书写也需要花费一定的时间，有时还需要不少时间。如只是从一次测试的效果来看单元测试多半是不划算的。单元测试解决的是之后代码改动之后再测试的时间。如果时间进度紧张，即使知道单元测试的好处也难有心去写。毕竟要先解决燃眉之急，更何况某些代码的生命周期很短，还不足以让单元测试发挥价值。
• 单元测试的基础测试数据需要积累
  一些复杂的业务系统业务数据之间的逻辑关系会比较复杂。比如你需要有基础的客户数据、员工数据后才可进行合同创建等功能的测试。如果没有前期测试数据的积累，你要直接给合同模块写单元测试。想到要将员工、客户等数据补上，立马就退缩了。（注：其实手动测试也要将员工、客户先创建好，只是因为之前手动测试时相关数据已创建好）

如何开始

• 在一些小项目中先用，真正体会一下单元测试的优点。
• 从项目的一开始就使用单元测试。单元测试的书写和项目的书写一样，都是一个循序渐进的过程。
• 只写一些必要的单元测试，不要最求大而全。即使手动测试你也不可能测试到所有小概率情况，所以可以只写一些最必要的单元测试，让单元测试代码发挥最大价值。