|
已锁定 主题： 程序员为什么不写单元测试
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-07-06
抛出异常的爱 写道 如果一个架构 的所有代码都是从A地拷贝一个东西到B地之后改改让它能用就行的开发方式。
我想没几个人能写出完全的测试的。 本质上那些 人就是拷贝代码的机器。 写测试是要求对业务有一定的了解基础之上的。 不了解业务是我见过所有有理由中最多的 也是了充分的。 拷别人的架构，相当于是用一个框架一样。当然是无需再测的了。 不了解业务就不测，不了解业务怎么能写代码啊？我的神啊！ 而单元测试恰恰是要你对需求的了解！！为什么不做呢？ |
| 返回顶楼 | |
|
发表时间：2007-07-06
引用 拷别人的架构，相当于是用一个框架一样。当然是无需再测的了。 不了解业务就不测，不了解业务怎么能写代码啊？我的神啊！ 而单元测试恰恰是要你对需求的了解！！为什么不做呢？ 我只是说事实而已 很多干了两三年的人在用过一次TDD之后 都不想放手， 但是一年经验的人固执的人很多。 |
| 返回顶楼 | |
|
发表时间：2007-07-06
抛出异常的爱 写道 引用 拷别人的架构，相当于是用一个框架一样。当然是无需再测的了。 不了解业务就不测，不了解业务怎么能写代码啊？我的神啊！ 而单元测试恰恰是要你对需求的了解！！为什么不做呢？ 我只是说事实而已 很多干了两三年的人在用过一次TDD之后 都不想放手， 但是一年经验的人固执的人很多。 这需要慢慢的引导！就像古代的人不穿鞋一样！ |
| 返回顶楼 | |
|
发表时间：2007-07-06
看了一个多小时终于看完了,现在算是初学者...
看了这么多,懂了些东西... 可是还是不知道怎样写单元测试... |
| 返回顶楼 | |
|
发表时间：2007-07-06
写和不写比较一下，选一个自己感到最舒服的方式就行了。
|
| 返回顶楼 | |
|
发表时间：2007-07-07
国内的客户需求的变更，国内软件企业的系统边界不能完全界定，盲目的追求什么技术，什么架构，造成了程序员疲于追赶，另外程序员还是存在一种为了工作而工作的想法 也是没有办法的事情，在反复的重复工作下，那点激情都没有了，还写测试，及时写也是不得已
|
| 返回顶楼 | |
|
发表时间：2007-07-07
面向接口测试，头一次听说。。。
单元测试的意义，《重构》,《TDD》,《without ejb》这些书已经讲了够多的了。 个人觉得，某些人（不应该称为程序员）不写单元测试，最大的原因还是在于没写过单元测试，和不会写单元测试。会写的人不会因为时间紧、麻烦、项目没有规定这些原因不写单元测试的。 公司，团队应该从技术管理上入手，落实一些针对单元测试的培训，规范和配置管理才比较有效。 |
| 返回顶楼 | |
|
发表时间：2007-07-07
badqiu 写道 对于lib型项目是推荐写单元测试,对多变的业务逻辑,力不从心
如果楼主最后能够一直坚持将dao,manager等一路写下来倒挺佩服的 注:曾经也是TDD的狂热者,现在是只对lib型项目写单元测试 lib输入输出明确肯定好写啦。 有些业务逻辑很复杂，改来改去也很频繁，更需要测试代码来保证，不然很快就自己都搞不懂来龙去脉了。 业务逻辑有时候很讨厌，要根据具体的业务数据测试，这就要注意测试的方法和粒度了，适当的重构把一些逻辑和数据分割开，针对逻辑测试会好一些。说得容易，做起来还是很麻烦。 dao,manager这些东西，有一些地方是可以忽略掉的。单元测试搞得太细了也不是甚么好事。生产代码和测试代码是 紧耦合的，造成对逻辑调整的包袱太重。 |
| 返回顶楼 | |
|
发表时间：2007-07-07
yanhua 写道 1.最终客户和开发人员都缺乏质量意识。客户缺乏判断软件质量尤其是代码质量的能力，认为软件当下能够运行就行而且功能越多越好，不客气的说，他们往往不知道自己想要什么也不知道什么能给他们带来真正的价值，就像喝惯了粗茶的舌头还觉得龙井寡淡无味。这样导致的后果就是软件的开发者根本没有创建高质量代码的动力，投客户的所好满足他们无休止的低级要求，能应付就应付，拿到钱就行啊。
2.公司注重眼前利益，追求低成本运营。做单元测试会增加成本吗？当然会！做一个汉堡当然要比做一个馒头的成本高，公司的管理者往往会认为客户给的是馒头的价格(即使客户给的是汉堡的价格，软件的价值对双方都太过虚妄了)那为什么要给他一个汉堡呢？--我想写点单元测试也得偷着写，不然老大会说：那么多事做不完，你还有时间写这个？你是不是思想有问题？工作态度有问题？ 3.开发人员水平的问题。如果写单元测试就象敏捷中说的那样是和系统在对话那么简单，对几句话能费什么事呢？--可是大部分开发人员写代码本来就不熟练，就像是结巴说话，费劲的很，能不说就不说吧。另外，写测试还不太难，要写出低耦合，易测试的代码却不容易，也许这正式TDD的一个好处，强迫你写出易测试的代码，但是大部分人在这之前就知难而退了。 客户、公司、开发人员都缺乏一种精益求精的精神……最后大家都没有好处！ 第一个问题是质量管理的问题，质量控制。 第二个问题技术管理的问题，老大能够说这样的话，可见一斑。 第三个问题人员管理的问题，人员素质的问题，人员培养的问题。 |
| 返回顶楼 | |
|
发表时间：2007-07-07
可以强制执行
写个脚本把测试没有跑到的代码全删了 这样没有测试的代码就不会被接受 |
| 返回顶楼 | |
