tdd*_*ing 4 language-agnostic tdd agile refactoring
我仍然是TDD的初学者,我常常陷入陷阱,在尝试添加新功能时,我已经将自己设计成了一个角落.
大多数情况下,这意味着在增加下一个要求时,从前10个要求中产生的API不会扩展,我意识到我必须对现有功能(包括结构)进行大量重新设计以添加内容新东西以一种很好的方式.
这很好,除非在这种情况下API会随之改变,因此所有初始测试都必须改变.这通常比重命名方法更重要.
我想我的问题是双重的:我应该如何避免首先进入这个位置,并且考虑到我进入它,重构测试的安全模式是什么,并允许新API的新功能增长？
编辑:很多很棒的答案,将试验几种技巧.标记为解决方案我觉得最有帮助的答案.
我该如何避免首先进入这个位置
最一般的规则是:在考虑重构时编写测试.特别是:
测试应该使用辅助方法,只要它们构造任何API特定的(即示例对象).这样,如果构造发生更改,您只有一个地方可以更改(例如,在向构造对象添加必填字段之后)
同样适用于检查API的输出
测试应构造为"默认差异",默认情况下由上面提供.例如,如果测试检查方法对字段的影响x,则应仅x在测试中设置字段,其余字段取自默认字段.
实际上,这些规则通常适用于代码.
什么是重构测试的安全模式,并允许新API的新功能增长？
每当您发现API更改使您在多个位置更改测试时,请尝试弄清楚如何将代码移动到一个位置.这是从上面得出的.