|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-04
yh_private 写道 gurudk 写道 yh_private 写道 抛出异常的爱 写道 主要看需求的写法
如果这回写错了， 下回写细一点。 必竟TDD是以不断变化为前题的。 哎~我们团队测试还在推广阶段，我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深，一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高，这个事情又不是靠逼就能逼出来的。 换个思路，代码评审对编码质量的提高更好。 代码评审如何给我们重构时带来勇气呢？难道每次重构就要把所有相关的代码全部审一遍，更何况表结构这样的变更需要非常细心的评审，实施起来恐怕比较难？ 勇气之类的是个虚词。。。。。 代码评审要时时刻刻作。。。。 每个svn记录后都要有人查看一次。。。 不然重构有什么意义？ |
| 返回顶楼 | |
|
发表时间：2008-08-04
抛出异常的爱 写道 勇气之类的是个虚词。。。。。 代码评审要时时刻刻作。。。。 每个svn记录后都要有人查看一次。。。 不然重构有什么意义？ 是不是虚词这个事情我不想讨论。至少我不喜欢去碰那些没有测试的代码。 代码评审我们是有的。我发这个帖子的意思是想问问大家在一个已经进行了几年的项目中，如何推广测试，如何让他们接受测试。而上面正是我现在存在的问题。数据不稳定如何进行测试？测试由浅入深。并且想请教下大家是如何在团队中推广测试的。而且我现在面临比较大的困难是，同志们通常很不习惯写测试。 |
| 返回顶楼 | |
|
发表时间：2008-08-05
我就是像你说的方法一那样做的，在setUp里new 出很多VO准备数据
另外每次都让hibernate重建表，每个测试后spring自动回滚事务 没觉得太麻烦，这样其实最稳定、最省事，一劳永逸 麻不麻烦，其实很大程度上取决于是否了解他的全部好处， 我坚信，一个程序员如果真的了解TDD到回报，是肯定愿意去麻烦一下的 |
| 返回顶楼 | |
|
发表时间：2008-08-05
抛出异常的爱 写道 勇气之类的是个虚词。。。。。 代码评审要时时刻刻作。。。。 每个svn记录后都要有人查看一次。。。 不然重构有什么意义？ 敏捷的四个核心理念之一——勇气，怎么变成虚词了啊？呵呵 靠肉眼评审，能保证重构成功了吗？（没有改变系统的接口和行为） |
| 返回顶楼 | |
|
发表时间：2008-08-05
daquan198163 写道 另外每次都让hibernate重建表，每个测试后spring自动回滚事务
没觉得太麻烦，这样其实最稳定、最省事，一劳永逸 
而且这个速度很快，一个test case以后就是一条rollback |
| 返回顶楼 | |
|
发表时间：2008-08-14
单元测试： 看代码覆盖率
集成测试：看业务操作覆盖率 不能一概而论，这两点我们处理的很理想，有兴趣可以讨论讨论 |
| 返回顶楼 | |
|
发表时间：2008-08-15
amonlei 写道 单元测试： 看代码覆盖率
集成测试：看业务操作覆盖率 不能一概而论，这两点我们处理的很理想，有兴趣可以讨论讨论 好.我现在的问题就是鼓励大家去写测试但似乎没有什么效果.因为是老项目.以前都没有什么测试代码的.大家也都习惯了没有测试的日子. 表现就是代码覆盖率是根本不动. 又不好逼着他们做测试.闲的时候都是去上网聊天.没见人主动做测试,而且给我找出N多理由. |
| 返回顶楼 | |
