处理TDD接口更改

Question

我已经开始使用TDD了。正如在an earlier question中提到的，最大的困难是处理接口更改。当需求变更时，您如何减少对测试用例的影响？

Answer 1

更改接口需要更新使用该接口的代码。在这方面，测试代码与非测试代码没有任何不同。该接口的测试将不可避免地需要更改。

通常，当一个接口发生变化时，你会发现“太多”的测试中断了，也就是说，大部分无关功能的测试最终都依赖于该接口。这可能是你的测试过于宽泛，需要重构的迹象。有许多可能的方法，但这里有一个例子，希望能展示一般的想法以及特定的情况。

例如，如果构造Account对象的方式发生了变化，并且这需要更新Order类的所有或大部分测试，那么一定是出了问题。大多数订单单元测试可能并不关心帐户是如何创建的，所以重构测试如下所示：

def test_add_item_to_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    order = Order(acct, shipping_addr)
    item = OrderItem('Purple Widget')
    order.addItem(item)
    self.assertEquals([item], order.items)

要这样做：

def make_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    return Order(acct, shipping_addr)

def make_order_item(self):
    return OrderItem('Purple Widget')

def test_add_item_to_order(self):
    order = self.make_order()
    item = self.make_order_item()
    order.addItem(item)
    self.assertEquals([item], order.items)

这个特殊的模式是一个Creation Method。

这里的一个优点是，您的Order测试方法与帐户和地址的创建方式是隔离的；如果这些接口发生更改，则只有一个地方可以更改，而不是恰好使用帐户和地址的每个测试。

简而言之:测试也是代码，就像所有代码一样，有时它们需要重构。

Answer 2

我认为这是流行的观点的原因之一，即接口使用得太多了。

然而，我不同意。

当需求改变时--你的测试也应该改变。对吗？我的意思是，如果您为其编写测试的标准不再有效，那么您应该重写或删除该测试。

我希望这能有所帮助，但我想我可能误解了你的问题。

Answer 3

将会有的影响。您只需要接受这样一个事实:更改接口首先需要时间来更改相关的测试用例。这是没有办法的。

然而，考虑到你节省的时间，你不会试图在这个界面中找到一个难以捉摸的bug，也不会在发布周修复这个bug，这是完全值得的。