嗯 我坚持design driven的说法 不许说我学术
其实呢 不管是tdd 还是design dd,关键是说:”哥们,想好了再下手“
很多时候,我都跟别人说,我们应该注释驱动。就是先把注释写得自己能看明白了再编程,毕竟 用自然语言表述的东西可理解性强很多
楼主的“注释驱动”在《代码大全》里有详细的描述,参看其中“伪代码编程”。这个和测试驱动并不冲突,伪代码编程的重点在整理出思路,完成功能的编码。测试驱动是要整理出功能,并确保功能正确实现。即使你用伪代码编程法完成了代码编写,就能保证正确吗?手工测试?发现错误,修改,再手工测试?呵呵,自动化测试的部分价值在这。另一部分价值是,想写出测试,就需要先知道测试什么,如果发现写不出测试,那就是功能还没完全定位准确,退回去仔细想想吧。
别说测试驱动否定设计,它在推着你设计呢。
问题就在于 测试驱动的驱动过于 low level了
在我随便写了这个comment之后,看到了 Ivan jacboson 的评论 你可以参考下
楼主很明显就没有搞明白为什么要“测试驱动开发”,关键就在于驱动二字之上,只有测试才能体现结果,才能证明你所做的行之有效。
设计也好,注释也好,都不能直接体现出来你编程的对错,而只是一个前提。也就谈不上去驱动你的开发了。
在代码级的开发上,我觉得测试驱动开发还是有用的,至少为代码的重构提供了更强的信心,并且测试用例也是可以随着代码的演变而调整的,甚至可以说测试和代码的演变可以互为驱动。