|
锁定老帖子 主题：尝试了一下把TDD用到真正的项目中
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-09-30
TDD应该也因人而异吧，但是有足够多的测试用例是必须的。有了足够多的测试，就敢重构了。
不能都写成黑盒吧，要测试内部的行为，测试间接的输入输出，可能需要mock，需要依赖注入或者lookup。 我们team通过review测试代码，互相提高。 |
| 返回顶楼 | |
|
发表时间：2009-09-30
gigix 写道 难道不应该是这样么？
assertEquals(7, vip.discount(10)); 而且…其实…难道不应该是这样么？ //flower is an item with price 10 assertEquals(7, flower.priceFor(vip)); 你的代码读起来很顺口呀 gigix 写道 所以…真的…能做出什么设计，和用什么方法来设计，关系不太大
谢谢你说的这么直白 
一下解决了我的困惑 俺是做对日外包的，基本套路是：操作类.process(数据类) 
还是你的代码漂亮：对象.sendMessage(对象) 继续对日下去，不知道该怎么让自己的代码OO一点，更漂亮一点 
|
| 返回顶楼 | |
|
发表时间：2009-09-30
daquan198163 写道 实现calculate时，根据直觉、设计模式、职责单一等等这些原则、思想，就可以驱动出userDao.isVIP
不必追求用测试驱动出所有接口、设计， TDD的本质是从调用者、客户的角度思考设计，既然calculator就是userDao的调用者，那么它驱动出的设计应该跟TDD效果是一样。的。 俺承认被忽悠了，或者说俺太希望：能切瓜砍菜般的驱动出开发 刚开始TDD，总想着怎么驱动怎么驱动，有点魔障了 谢谢你给出的建议 firebody 写道 TDD有一个原则：尽量让你的代码易测。
怎么评判易测和难测的呢？ 其实很简单，那就看你准备测试数据的步骤是否很难。 这个建议很好操作
现阶段写测试时觉得烦人的地方有两点： 1.一大坨的准备数据，烦 2.关联对象太多，导致mock或者stub很多，烦 好，我现在的目标就是让准备数据易于构造，减少需要mock和stub的地方 |
| 返回顶楼 | |
|
发表时间：2009-09-30
最后修改：2009-09-30
ablmf 写道 哪些是应该需要测试的，这个判断是很重要的一件事情。
很重要，也很简单 任何达到或超过三行或两个逻辑分支的函数都需要测试 |
| 返回顶楼 | |
|
发表时间：2009-10-01
最后修改：2009-10-01
实践TDD时，也遇到和楼主一样的困惑就是效率低下
个人的经验就是 1 用TDD保障需求基本正确：自顶向下的测试——也就是只测试需求，基本上可以保证功能的基本正确性 bug除外:) 2 用TDD控制BUG：主要利用TDD防止bug的重复发生，这个要求透彻分析bug产生的原因然后针对这样的情形“精心”设计测试用例，保证以后不会发生相同的问题 第一条保证了软件功能有基本保证 第两条保证软件的bug不会重复发生，同时fix后因为有第一条保证，所以bug的fix不会使功能失效 第一条时间上：因为构件的测试用例只有最上层，时间上用时最少，TDD的要求基本上从上到下都要写测试用例，特别是分层的时候 第两条时间上：很多低级错误基本上不会发生，为这些可能错误而精心构件测试划不来，基本上bug都是隐藏的逻辑错误，只会在特定条件下才会发生，使用TDD先写测试，也不一定会发现他们，与其花费时间精心构造测试，不如先放放，等问题发生了再去构造测试。这样省掉了精心构造各种情形下的测试用例。 TDD的本质也是保障测试过的代码随着时间推移不会发生失效 通过以上简化的测试，只是保障了测试过得功能随着时间推移，基本能够保证正确性 （其实无论那种方法都无法保障绝对的无bug） 以上是个人的一点心得！ |
| 返回顶楼 | |
|
发表时间：2009-10-01
gigix 写道 ablmf 写道 哪些是应该需要测试的，这个判断是很重要的一件事情。
很重要，也很简单 任何达到或超过三行或两个逻辑分支的函数都需要测试 这个是测试 效率的杀手阿。 很多时候这样的代码确实是没有问题的！ 我觉得可以针对不同人实行，对于代码质量差的人，就是经常发生低级错误的，严格执行这样的测试要求 对于有经验的人可以放宽，只作功能性测试！发生bug时再精心构造测试 |
| 返回顶楼 | |
|
发表时间：2009-10-01
哪怕你为了TDD而去TDD,你也会发现为了使你的代码能够被测试,代码本身已经变得足够整洁和清晰了,这是最低且是最大的效果
另外测试和测试驱动开发的区别还是很大的,你现在的行为只是用规范测试代替运气,并不能算是TDD |
| 返回顶楼 | |
|
发表时间：2009-10-07
gigix 写道 引用 testCalculateForVIP() {
price = calculate(vip, 10);
assert price == 7;
}难道不应该是这样么？ assertEquals(7, vip.discount(10)); 而且…其实…难道不应该是这样么？ //flower is an item with price 10 assertEquals(7, flower.priceFor(vip)); 所以…真的…能做出什么设计，和用什么方法来设计，关系不太大 看到gigix所写，突然领悟了一点什么，但是又说不上来。 被设计思想袭击？ |
| 返回顶楼 | |
|
发表时间：2009-10-10
gigix 写道 ablmf 写道 哪些是应该需要测试的，这个判断是很重要的一件事情。
很重要，也很简单 任何达到或超过三行或两个逻辑分支的函数都需要测试 这个程度我做不到，而且我觉得从“两个逻辑分支”这个角度来做测试，已经算不上是TDD了。 |
| 返回顶楼 | |
|
发表时间：2009-10-10
最后修改：2009-10-10
ablmf 写道 gigix 写道 ablmf 写道 哪些是应该需要测试的，这个判断是很重要的一件事情。
很重要，也很简单 任何达到或超过三行或两个逻辑分支的函数都需要测试 这个程度我做不到，而且我觉得从“两个逻辑分支”这个角度来做测试，已经算不上是TDD了。 第一，为什么你做不到？整个项目做不到，找一个1000行的模块来做行不行？只在一个类里做行不行？找个人教你怎么做行不行？是做不到，还是没有做，还是根本就不想做？ 第二，既然你做不到，后面那个“觉得”是从哪里觉出来的呢？你要是真的在TDD，没有测试之前，你根本就不会写出逻辑分支。为什么不会写？你想过的东西都用测试描述出来了，你想都没想过的逻辑分支又怎么会写出来？ |
| 返回顶楼 | |
