|
已锁定 主题： 程序员为什么不写单元测试
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-07-07
少一点Why，大道理说服不了多少人。多说一点How，多给一些实际的例子！
例如，我这里很多程序依赖几十个DAO，而且很多DAO中实际是包含很多业务逻辑的。请问这个单元测试如何做？很多Service中只是逐一调用这些DAO(transaction script)，对Service的单元测试的意义有多大？ 例如这是一个DAO的sql语句(ibatis)
select c.contract_id as contractId,
c.eff_date as effDate,
c.end_date as endDate
from pts_contract_info c
where c.contract_type =#contractType#
and c.plan_register_no =#planRegisterNo#
and (c.end_date = (
select
max(c.end_date)
from
pts_contract_info c
where
c.contract_type = #contractType#
and c.plan_register_no = #planRegisterNo#
) or c.end_date is null
)
|
| 返回顶楼 | |
|
发表时间：2007-07-07
稍微复杂点的逻辑可能会写个测试，说是测试，其实就是加个main方法，而且这个main方法最后还可能被无情的删除。
如果说测试是一种责任，那么我不得不说一下我们公司，注释啊，同志们！ 公司的底层数据库操作是自己的框架，再加一层service，那个注释写的，跟没写一样，看起来真叫累，所以现在我写代码注释都打的非常详细。 如果说不写测试是不负责任，那么不写注释的同志们就该拉出去痛打一顿！ |
| 返回顶楼 | |
|
发表时间：2007-07-07
zkgale 写道 看了一个多小时终于看完了,现在算是初学者...
看了这么多,懂了些东西... 可是还是不知道怎样写单元测试... 下一篇文章我会写 |
| 返回顶楼 | |
|
发表时间：2007-07-07
dykl001 写道 国内的客户需求的变更，国内软件企业的系统边界不能完全界定，盲目的追求什么技术，什么架构，造成了程序员疲于追赶，另外程序员还是存在一种为了工作而工作的想法 也是没有办法的事情，在反复的重复工作下，那点激情都没有了，还写测试，及时写也是不得已
|
| 返回顶楼 | |
|
发表时间：2007-07-07
joachimz 写道 少一点Why，大道理说服不了多少人。多说一点How，多给一些实际的例子！
例如，我这里很多程序依赖几十个DAO，而且很多DAO中实际是包含很多业务逻辑的。请问这个单元测试如何做？很多Service中只是逐一调用这些DAO(transaction script)，对Service的单元测试的意义有多大？ 例如这是一个DAO的sql语句(ibatis)
select c.contract_id as contractId,
c.eff_date as effDate,
c.end_date as endDate
from pts_contract_info c
where c.contract_type =#contractType#
and c.plan_register_no =#planRegisterNo#
and (c.end_date = (
select
max(c.end_date)
from
pts_contract_info c
where
c.contract_type = #contractType#
and c.plan_register_no = #planRegisterNo#
) or c.end_date is null
)
下一篇文章我会详细的写怎么写单元测试 |
| 返回顶楼 | |
|
发表时间：2007-07-07
javaTo 写道 稍微复杂点的逻辑可能会写个测试，说是测试，其实就是加个main方法，而且这个main方法最后还可能被无情的删除。
如果说测试是一种责任，那么我不得不说一下我们公司，注释啊，同志们！ 公司的底层数据库操作是自己的框架，再加一层service，那个注释写的，跟没写一样，看起来真叫累，所以现在我写代码注释都打的非常详细。 如果说不写测试是不负责任，那么不写注释的同志们就该拉出去痛打一顿！ 用junit ,不要写main方法 |
| 返回顶楼 | |
|
发表时间：2007-07-07
Godlikeme 写道 面向接口测试，头一次听说。。。
单元测试的意义，《重构》,《TDD》,《without ejb》这些书已经讲了够多的了。 个人觉得，某些人（不应该称为程序员）不写单元测试，最大的原因还是在于没写过单元测试，和不会写单元测试。会写的人不会因为时间紧、麻烦、项目没有规定这些原因不写单元测试的。 公司，团队应该从技术管理上入手，落实一些针对单元测试的培训，规范和配置管理才比较有效。 架构师和项目经理是有责任的。有没有做好基础的工作，让单元测试更容易写一些！ 后继文章我会继续这个话题的。 现在是说why 后继文章我会说how |
| 返回顶楼 | |
|
发表时间：2007-07-07
好哇，能够讲讲how，比较期待，
|
| 返回顶楼 | |
|
发表时间：2007-07-07
Godlikeme 写道 好哇，能够讲讲how，比较期待，
这是一个系列文章！ 在实际的开发中我是头大了，越是工作多年的程序员，越是不写单元测试。还有一大堆的理由！ 没有什么工作经验的呢，又不会写单元测试。真是头大了！ btw:怎么样才能评为精华？ |
| 返回顶楼 | |
|
发表时间：2007-07-07
joachimz 写道 少一点Why，大道理说服不了多少人。多说一点How，多给一些实际的例子！
例如，我这里很多程序依赖几十个DAO，而且很多DAO中实际是包含很多业务逻辑的。请问这个单元测试如何做？很多Service中只是逐一调用这些DAO(transaction script)，对Service的单元测试的意义有多大？ 例如这是一个DAO的sql语句(ibatis)
select c.contract_id as contractId,
c.eff_date as effDate,
c.end_date as endDate
from pts_contract_info c
where c.contract_type =#contractType#
and c.plan_register_no =#planRegisterNo#
and (c.end_date = (
select
max(c.end_date)
from
pts_contract_info c
where
c.contract_type = #contractType#
and c.plan_register_no = #planRegisterNo#
) or c.end_date is null
)
我觉得你的程序应该有些问题了吧，对于业务逻辑来说应该是放在service中的，Dao的作用应该是单纯的与数据库进行交互的，不应该包含过多的业务规制。想一下就知道，如果你的需求中业务规则发生了改变，你竟然要去改与数据库交互的Dao层代码，这想想就知道有问题了吧。Service的职责才是实现业务逻辑，你的程序中把原本属于Service的职责放到了Dao中了，那你的Service只是简单的委托，OH！？ Service的测试就应该是用一些mock实现的Dao来测试业务流程执行的正确性，用mock来注入Dao的话，测试Service的情况就和测试一般JavaBean差不多了。输入一些测试数据，然后断言它在经过了Service的业务流程之后是否达到了预定的情况。 而对于Dao，你可以用DBUnit来进行测试，DBUnit可以用预先提供好的数据集对Dao的操作进行自动化测试。如果是使用Spring来管理ibatis的话，可以继承自 Spring 的AbstractTransactionalDataSourceSpringContextTests类，这也是官方推荐的做法。AbstractTransactionalDataSourceSpringContextTests 对测试方法提供了事务管理，同时它的依赖注入特性也方便测试类注入被测试类。这样就可以对Dao进行单元测试了。 |
| 返回顶楼 | |
