程序员为什么不写单元测试

还在期待LZ的“如何做单元“(How)。

对于单元测试的意义，我觉得大部分人都会认可。但肯定有很多困难，只有帮助分析和解决这些困难，才能真正地推动单元测试。

以我自己为例，我一直希望能在项目和团队中推行单元测试，但是各种环境、设计问题，常常导致测试实际难以推行，目前我只能尽量灌输一些面向测试的设计和开发，让一些有复杂逻辑的程序尽量少的与环境榜定，便于测试。

但由于我们系统架构上是采用分布式，大量采用无状态服务的设计思路，服务于服务之间相互依赖严重，因此如果做单元测试，有大量的Mock工作要做，感觉代价太大，成果不多。
但另一方面，如果为了测试，通过重构，抽离业务逻辑脱离环境，又很困难，会给程序带来一些不必要的复杂性。

期待更多人能分享一些自己工作中的实践经验，或者例子。

代码是产品的最终设计，产品的质量和代码的质量有直接关系。不认识到这一点，程序员是不会认真对待代码的。

做好单元测试，可以在后面的测试阶段少很多bug,很重要的。楼主的话很有道理，强烈支持

唉,过犹不及,单元测试如是, 注释亦如是


本人见过最过份的单元测试是对Java Bean的每个get,set都做单元测试

难于测试的代码一般是由于框架，业务不熟悉
楼上所说的大约是由于先写代码所导致的。PS：重覆就意味着重构。

根本原因还是我们自身的业务素质还不够啊

根本原因还是不想尝试新的编程态度啊。。。。

正解。。。项目需求不断变更，人员流动大。。。
归结到一点，项目流程不规范。。。

以上是部分原因。。。

好贴

也说说我的意见

1：提到log4j、junit和ant

我也做了很多年的项目开发
log4j不是一定要用，我对log4j感觉不好，所以很早以前就自己写了一个log工具。但log对于service来说很必要，尤其运行期间。所以能不能够很好的记录log是很关键的。至于什么样的log工具看自己习惯了。我已经习惯于用自己的工具了。

junit也不错
不过不是不用它就说明你菜的。它能够提供的单元测试功能很有限。我觉得用main函数也可以代替。只不过有点麻烦。不过是习惯不同而以。重点在于测试方法体怎么写

ant我也不是很熟。
很多IDE里都有封装了的打包运行工具。由于我一直在windows下编程，所以ant不怎么用。


2：注释
我从来不觉得注释是非要不可的
如果你是提供一个API或者一个公用方法，注释就很必要
但也不是

/**
* 记录数据到本地文件
* @param data 数据
* @param path 文件位置
*/

这种注释意义不大
可以参考很多工具api的注释，里面不但写明了方法作用，参数，还会讲述如何使用、注意事项和一些基本原理，这才是重要的
而对于内部一些类，与其像上面那样写注释，不如把变量名取好


3：单元测试
这个是重中之重
我觉得应该讨论几点
1）如何做单元测试
2）单元测试如何评定
3）单元测试的粒度怎么掌握
这三点不弄清楚，单元测试就像一层雾一样，很多程序员都会觉得似乎碰到了它，可又不知道是不是真的在里面
1）其实我也期待lz可以快点把它弄出来
对于一个小项目的一个方法

public double plus(double a1,double a2){
  return a1+a2;
}

这个做单元测试，谁都会
可如果复杂一点的方法，比如用户数据系统
得到处于工作状态的用户，能够通过性别，年龄和区域查询
public ArrayList getBusyUsers(int maleType,int ageLine,Local local){
}
这个方法可能在一个系统里只是一个功能性的小方法，却需要数据库、运行服务等配合，如果遇到多服务，那就更麻烦了。而对于一个系统来说，类似于这样的单元测试更重要，也更有意义。
我们可以把这样的方法拆分成无数个小方法，对每个小方法作测试，可是这样测出的结果和组合后的结果会有差别的。

2）一个单元测试是不是成功，怎么个评价方法呢？
简单的例子

public double divide(double a1,double a2){
return a1/a2;
}

对于这样一个最简单的例子，测试者先写测试代码，因为他简单，所以预先设计了一组数字，测试和预想完全一样，测试成功。
可是，当a2=0的情况没有考虑到，结果bug遗漏。
为了避开因为经验不足和考虑不周全而产生的遗漏，test case 需要可以尽量罗列可能的数值。这样测试程序一下子就复杂了。而对于这个小方法，使用一个很庞大的测试程序，会让程序员感到杀鸡用牛刀。最终也会放弃测试了。

3）粒度问题
其实说来说去都离不开这个粒度问题
粒度小，测试内容就很多，在测试代码上需要花的时间就多。而对于大粒度的东西，如我1）里提到的业务逻辑部分，单元测试就非常复杂。这样出现的结果是。
1很多程序员为了单元测试而单元测试，避开大逻辑部分，而是对小模块方法来测试，结果真正需要单元测试的被遗漏了
2在对小模块的单元测试中，如2）中提到的例子，因为单元小，所以测试写的不完全，结果每次测试都似乎无用，降低了单元测试的必要性（对程序员的感觉上）
最终单元测试从一个代码历程里分离出来。
再考虑到时间和个人对工作量的把握上有点出入，慢慢的就会走向由单元测试要求，变为只有在感觉上需要的时候才去测试。


这些是我的看法，也是我的经历。
我想，除非在一个很成熟的开发环境下：大家都做单元测试；项目不会因为时间问题而赶工；项目下来时就考虑到测试时间；程序员在平时不会因为每天的任务量而加班；项目结束后不是可以运行就可以上线，而是要有很高的效率和稳定性才可过关。不然做到每个case or function都要test是很难的。

不写单元测试不是公司管理的问题，因为这个是对程序员有好处的，TDD能够提高程序员开发效率的，理由楼主已经说的很清楚了，不再解释！
根据我的经验原因有三：
1.不知道写单元测试的好处。
2.不知道怎么写单元测试。
3.知道单元测试工具(如JUNIT)怎么用，但是严重缺乏设计能力，导致自己写的模块无法测试（高耦合，低内聚）。

前两个原因好办，如果是第三个原因，赶快学习OO和设计模式吧，提高自己的设计能力。