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

程序员自己明白了自己会去做滴！但是通常都不做

我觉得编写测试类是很有意义的。
做为整个项目可以保证质量，减少成本。
作为程序员个人，可以实时的模拟运行情况，可能会出现问题的情况，不断的完善自己的类。
对个人还是公司都是很有益的。

更多的不愿意写测试类的人可能更多的原因是为了节约时间或自己想不出更多的测试用例罢了。
做为程序员还是规范些的好。

其实就像我文章所说，写单元测试获得最大的好处的是程序员！而不是其它人！
但是往往，程序员会找各种理由拒绝写单元测试！

佩服搂主的语言功底。看的我都快睡觉了。其实写单元测试是需要一个环境的，难吗？不难？就看公司技术主管要求不要求了。

对于lib型项目是推荐写单元测试,对多变的业务逻辑,力不从心
如果楼主最后能够一直坚持将dao,manager等一路写下来倒挺佩服的

注:曾经也是TDD的狂热者,现在是只对lib型项目写单元测试

1.最终客户和开发人员都缺乏质量意识。客户缺乏判断软件质量尤其是代码质量的能力，认为软件当下能够运行就行而且功能越多越好，不客气的说，他们往往不知道自己想要什么也不知道什么能给他们带来真正的价值，就像喝惯了粗茶的舌头还觉得龙井寡淡无味。这样导致的后果就是软件的开发者根本没有创建高质量代码的动力，投客户的所好满足他们无休止的低级要求，能应付就应付，拿到钱就行啊。

2.公司注重眼前利益，追求低成本运营。做单元测试会增加成本吗？当然会！做一个汉堡当然要比做一个馒头的成本高，公司的管理者往往会认为客户给的是馒头的价格(即使客户给的是汉堡的价格，软件的价值对双方都太过虚妄了)那为什么要给他一个汉堡呢？--我想写点单元测试也得偷着写，不然老大会说：那么多事做不完，你还有时间写这个？你是不是思想有问题？工作态度有问题？

3.开发人员水平的问题。如果写单元测试就象敏捷中说的那样是和系统在对话那么简单，对几句话能费什么事呢？--可是大部分开发人员写代码本来就不熟练，就像是结巴说话，费劲的很，能不说就不说吧。另外，写测试还不太难，要写出低耦合，易测试的代码却不容易，也许这正式TDD的一个好处，强迫你写出易测试的代码，但是大部分人在这之前就知难而退了。

客户、公司、开发人员都缺乏一种精益求精的精神……最后大家都没有好处！

我倒觉得该是一个素质问题，如果你主动的去做了，你就会获益！

单元测试正是用来保证这些变化的！

我并不认为单元测试会增加成本！事实上也没有增加成本！反而是节约了成本！为什么？
文章已经说得够清楚了！

我始终认为单元测试是一个意识的问题，是一个程序员的素质问题。

如果一个架构 的所有代码都是从A地拷贝一个东西到B地之后改改让它能用就行的开发方式。
我想没几个人能写出完全的测试的。
本质上那些 人就是拷贝代码的机器。

写测试是要求对业务有一定的了解基础之上的。
不了解业务是我见过所有有理由中最多的
也是了充分的。

如果你想要说重构的话，那又是另一话题了。