unit-testing - 处理 TDD 接口(interface)更改

Question

我已经开始使用 TDD。如 an earlier question 中所述最大的困难是处理界面变化。随着需求的变化，您如何减少对测试用例的影响？

Answer 1

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

通常，当接口(interface)更改时，您会发现“太多”测试中断，即对大部分不相关功能的测试结果依赖于该接口(interface)。这可能表明您的测试过于广泛，需要重构。发生这种情况的方式有很多种，但这里有一个示例，希望能展示总体思路和特定案例。

例如，如果构造 Account 对象的方式发生了变化，这需要更新您的 Order 类的全部或大部分测试，那么就会出现问题。大多数 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 测试方法与 Accounts 和 Addresses 的创建方式是隔离的；如果这些接口(interface)发生更改，您只有一个地方可以更改，而不是碰巧使用帐户和地址的每个测试。

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