|
锁定老帖子 主题：TDD
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-01-24
蓝皮鼠 如果有实际的例子讲解一下就更好了，最好选个复杂一点的
|
| 返回顶楼 | |
|
发表时间：2010-01-28
chanball 写道 蓝皮鼠 如果有实际的例子讲解一下就更好了，最好选个复杂一点的
复杂了就T不了了 一般要是真的很复杂.... 以至于我不能快速写出测试的话 我都不写测试的 (真的不愿意写就不写) 我第一次TDD是由于EJB启动一次需要十多分钟... 如果你的项目启动一次需要那么长时间用一次TDD就会爱上它 TDD还有好处就是改的快 只要先把测试加了 之后就不想别的只要改代码让绿条出了就OK了 不用提心掉胆的改代码 . 比如一个工具 要输入两个时间 输出一个list 里面是 这两个时间之间的 自然天的启止时间 用来查寻 我就把页面上传过来的东西向里一放 把预想值一写 什么边界 什么入参的正确性啊 什么个数多了少了 什么都 不管了 只要预想对了 代码 就对了 脑子不用记那么我东西. 当然这个工具写完了之后 在用的时候还是有bug 别人踢回来后 我又加了一个测试 就是那个bug所真存在的数据 改改就绿了. 这要放以前 读这代码 得用半天时间 找到问题不得再用半天时间? 改了之后测以前的功能没被破坏再来一天 加上写测试改这个bug用了30分钟. 我还能保证以前的功能 没被 破坏. 现在除了页面拦截器不太会测还在用着原始的方式 写好了再看其它都尽量去写测试了. 有些特别少写的代码我都不太会测试 主要是人懒.... |
| 返回顶楼 | |
|
发表时间：2010-01-29
我现在知道自己酒后犯了一个什么样的错误了，TDD这顶帽子已经被戴在固定的脑袋上，可是咱重新起个什么名字好呢？TDDD=测试数据驱动开发，TD3，嗯，这个名字不错。
|
| 返回顶楼 | |
|
发表时间：2010-01-29
一蓑烟雨任平生 写道 我现在知道自己酒后犯了一个什么样的错误了，TDD这顶帽子已经被戴在固定的脑袋上，可是咱重新起个什么名字好呢？TDDD=测试数据驱动开发，TD3，嗯，这个名字不错。
如果测试开发成型了. 我想我会改进框架. 来提高效率 或者自己写个轮子. 反正能少写点代码就少写点 数据开发这种事还是由于技术水平没到那个台阶面前. 好高骛远的达到thoughtworkes的tdd水平 我所在的小组在没人带领的条件下 自发完成用三四年也是很有可能的. 当然 最大的可能是下个月底拆团重建 |
| 返回顶楼 | |
|
发表时间：2010-02-02
最后修改：2010-02-02
一概而论TDD是很难讨论出什么有意义的结论的。不妨我们把TDD定义为：
1、针对Compilation Unit（也就是类和方法）的Unit Test 2、只管红绿条的节奏，无明确指导目标的重构。而所谓的“Design”会神奇地被“Drive”出来。 如果同意这个说法，那么这样的TDD是非常有害的。 （参见James Coplien 在2008年Oredev会议上的演讲“Agile Fine Tuning” http://archive.oredev.org/topmenu/video/agile/jamescoplienagilefinetuning.4.5a2d30d411ee6ffd2888000599.html） 关于第一点。针对编译单元级别的Unit Test很难真正起到什么正面的作用。相反会增加代码之间的耦合。因为Unit不光是和其他的Production code Unit耦合在了一起，还和Unit Test耦合在了一起。这样的耦合往往直接形成了重构的阻力。因为任何有现实意义的重构，都是在Unit之间调整职责。在这样的调整过程，很难保证compilation unit这个层面的接口是稳定的。让问题更加恶化的是对Mock的滥用。从而形成了一点重构红一片的现象。 我个人已经缺省不在编译单元这个层面做Unit test，除非它包含了确实自成体系值得一测的东西。但是这个并不是说不做Unit test。我们应该把对Unit的理解提升一点。一个Compilation unit往往不是自成体系的，它们需要和它们的协作者拼在一起才能完成一定的功能。如果分包做得好，实现一个功能的相关的Compilation unit应该内聚在一个包内。而这个包才是真正值得测试的Unit。 关于第二点，参见Rebecca Wirfs-Brock 关于What drives design的演讲http://www.infoq.com/presentations/What-Drives-Design-Rebecca-Wirfs-Brock。一开始TDD的D是Development。有印象是Jimmy Nilsson这个很cuo的家伙把这个D换成Design的。没有任何证据表明TDD会减少coupling增强cohesion。倒是有很多实践表明，TDD很容易让代码写成procedural的。 |
| 返回顶楼 | |
|
发表时间：2010-02-03
一蓑烟雨任平生 写道 要这么说就没劲了。
这么多年一直在项目一线，见过的门派多了。各家招式不一样，不会打还不能评价？ 不过，我还是真的好奇，真正的TDD怎么做？ 不是段誉也可以是王语嫣哦 |
| 返回顶楼 | |
|
发表时间：2010-02-03
最后修改：2010-02-03
一蓑烟雨任平生 写道 我现在知道自己酒后犯了一个什么样的错误了，TDD这顶帽子已经被戴在固定的脑袋上，可是咱重新起个什么名字好呢？TDDD=测试数据驱动开发，TD3，嗯，这个名字不错。
可以和这位合作下： ronghao 写道 数据驱动测试
http://www.iteye.com/topic/542452 DTT -> TD3 
|
| 返回顶楼 | |
|
发表时间：2010-02-03
taowen 写道 一概而论TDD是很难讨论出什么有意义的结论的。不妨我们把TDD定义为：
1、针对Compilation Unit（也就是类和方法）的Unit Test 2、只管红绿条的节奏，无明确指导目标的重构。而所谓的“Design”会神奇地被“Drive”出来。 如果同意这个说法，那么这样的TDD是非常有害的。 （参见James Coplien 在2008年Oredev会议上的演讲“Agile Fine Tuning” http://archive.oredev.org/topmenu/video/agile/jamescoplienagilefinetuning.4.5a2d30d411ee6ffd2888000599.html） 关于第一点。针对编译单元级别的Unit Test很难真正起到什么正面的作用。相反会增加代码之间的耦合。因为Unit不光是和其他的Production code Unit耦合在了一起，还和Unit Test耦合在了一起。这样的耦合往往直接形成了重构的阻力。因为任何有现实意义的重构，都是在Unit之间调整职责。在这样的调整过程，很难保证compilation unit这个层面的接口是稳定的。让问题更加恶化的是对Mock的滥用。从而形成了一点重构红一片的现象。 我个人已经缺省不在编译单元这个层面做Unit test，除非它包含了确实自成体系值得一测的东西。但是这个并不是说不做Unit test。我们应该把对Unit的理解提升一点。一个Compilation unit往往不是自成体系的，它们需要和它们的协作者拼在一起才能完成一定的功能。如果分包做得好，实现一个功能的相关的Compilation unit应该内聚在一个包内。而这个包才是真正值得测试的Unit。 关于第二点，参见Rebecca Wirfs-Brock 关于What drives design的演讲http://www.infoq.com/presentations/What-Drives-Design-Rebecca-Wirfs-Brock。一开始TDD的D是Development。有印象是Jimmy Nilsson这个很cuo的家伙把这个D换成Design的。没有任何证据表明TDD会减少coupling增强cohesion。倒是有很多实践表明，TDD很容易让代码写成procedural的。 可不可以理解为： 尽量写package或模块级别的集成测试； 测试尽量黑盒，只关心输入输出，不关心内部逻辑； 设计也不要指望靠测试来神奇的驱动出来，还是要靠合理的使用设计模式、遵循OO原则。 ps：该mock的地方还是要mock，比如外部通信。 |
| 返回顶楼 | |
|
发表时间：2010-03-05
恩，我发现我最近在做的仅仅是单元测试 而不是tdd
|
| 返回顶楼 | |
