我阅读了最新的编码恐怖帖子,其中一条评论让我感到不安:
这是测试驱动设计/重构应该修复的情况类型.如果(大的话)你有接口测试,重写实现是没有风险的,因为你会知道你是否抓住了一切.
现在,在理论上我喜欢测试驱动开发的想法,但我试图使它工作的所有时间,但一直没有去特别好,我出去的习惯,而接下来的事情我知道所有的测试,我最初写的不仅没有通过,而且它们不再是系统设计的反映.
如果你从一开始就从高处直接交给一个完美的设计(根据我的经验从未实际发生过),这一切都很好,但是如果你在制作系统的中途发现有一个关键的缺陷怎么办呢？该设计？然后它不再是潜入和修复"bug"的简单问题,但你还必须重写所有的测试.一个基本假设是错误的,现在你必须改变它.现在,测试驱动的开发不再是一个方便的东西,但它只是意味着完成所有工作的工作量是其两倍.
我之前尝试过这个问题,包括同行和在线,但我从未听过一个非常令人满意的答案.......哦等等......问题是什么？
您如何将测试驱动开发与必须更改的设计相结合,以反映对问题空间日益增长的理解？你如何让TDD练习为你工作而不是对你有用？
更新: 我仍然不认为我完全理解这一切,所以我无法真正决定接受哪个答案.我的大部分理解都发生在评论部分,而不是答案中.这是迄今为止我最喜欢的收藏品:
"在软件开发中使用像"无风险"这样的术语的人确实充满了蠢事.但是不要因为一些支持者极易受到炒作而注销TDD.我发现这有助于我在写作之前澄清我的想法一大堆代码,帮助我重现bug并修复它们,让我在重新开始看起来丑陋的时候更有信心"
-Kristopher Johnson
"在这种情况下,你只重写了已经改变的接口部分的测试,并认为自己很幸运,在其他地方有良好的测试覆盖率,可以告诉你其他对象依赖于它."
-rcoder
"在TDD中,编写测试的原因是进行设计.使测试自动化的原因是你可以在设计和代码发展时重复使用它们.当测试中断时,它意味着你以某种方式违反了早期设计决定.也许这是你想要改变的决定,但最好尽快得到反馈."
-Kristopher Johnson
[关于测试接口]"测试会插入一些元素,检查大小是否与插入的元素数量相对应,检查contains()是否为它们返回true但是对于未插入的元素,检查remove()是否有效对于所有实现,所有这些测试都是相同的,当然你会为每个实现运行相同的代码而不是复制它.所以当界面改变时,你只需要调整一次测试代码,而不是每次实施一次."
-Michael Borgwardt
这不再是深入研究并修复“错误”的简单问题，而且您还必须重写所有测试。
TDD 的基本信条是避免生产代码和测试代码中的重复。如果单个设计更改意味着您必须重写所有内容，那么您就没有执行 TDD（或者根本没有正确执行）。
理想情况下，在一个设计良好且适当分离关注点的系统中，设计更改是局部的，就像实现更改一样。虽然现实世界很少是理想的，但您通常仍然会得到介于两者之间的东西：您必须更改一些生产代码和一些测试，但不是全部，并且更改大多很简单，甚至可以通过重构工具自动完成。