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