处理TDD接口更改

我已经开始使用TDD了.正如前面提到的问题中提到的,最大的困难是处理界面变化.随着需求的变化,您如何减少对测试用例的影响？

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

通常,当接口发生变化时,您会发现"太多"测试中断,即对大部分不相关的功能的测试结果依赖于该接口.这可能表明您的测试过于宽泛并需要重构.有许多可能的方法可以实现,但这里有一个例子,希望能够显示一般的想法以及特定的案例.

例如,如果构造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)

这种特殊模式是一种创建方法.

这里的一个优点是Order的测试方法与创建Accounts和Addresses的方式不同; 如果这些接口发生变化,您只需要更改一个地方,而不是每次尝试使用帐户和地址.

简而言之:测试也是代码,与所有代码一样,有时它们需要重构.

我认为这是时髦论证界面使用过多的原因之一.

但是,我不同意.

当需求发生变化时 - 您的测试也应如此.对？我的意思是,如果您编写测试的标准不再有效,那么您应该重写或删除该测试.

我希望这会有所帮助,但我想我可能误解了你的问题.