处理TDD接口更改

时间:2008-09-26 13:03:37

标签: unit-testing tdd

我已经开始使用TDD了。正如an earlier question中提到的,最大的困难是处理界面变化。当需求发生变化时,您如何减少对测试用例的影响?

9 个答案:

答案 0 :(得分:7)

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

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

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

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

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

答案 1 :(得分:6)

认为这是接口使用过多的时髦论据的原因之一。

但是,我不同意。

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

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

答案 2 :(得分:4)

影响。您只需接受更改界面将需要时间来首先更改关联的测试用例。没有办法解决这个问题。

然而,你考虑节省时间,不要试图在以后的界面中找到一个难以捉摸的bug,而不是在发布周期间修复那个bug,这是值得的。

答案 3 :(得分:1)

在TDD中,您的测试不是测试。它们是可执行的规范。 IOW:它们是您的要求的可执行编码。 始终牢记这一点。

现在,突然间变得很明显:如果您的需求发生变化,那么测试必须更改!这就是TDD的重点!

如果您正在使用瀑布,则必须更改规范文档。在TDD中,你必须这样做,除了你的规范不是用Word编写的,它是用xUnit编写的。

答案 4 :(得分:1)

“我们应该做些什么来防止我们的代码和测试依赖于请求?似乎什么都没有。每次更改我们必须更改我们的代码和测试。但也许我们可以简化我们的工作?是的,我们可以。关键原则是:包含可能被更改的代码。“

http://dmitry-nikolaev.blogspot.com/2009/05/atch-your-changes.html

答案 5 :(得分:0)

在编写新界面的代码之前编写测试。

答案 6 :(得分:0)

如果您遵循Test First方法,理论上应该不会影响测试代码的界面更改。毕竟,当您需要更改接口时,您首先要更改测试用例以符合要求,然后继续更改接口/实现,直到测试通过。

答案 7 :(得分:0)

当接口改变时,您应该期望测试中断。如果太多测试中断,这意味着您的系统耦合太紧,太多东西依赖于该接口。你应该期待一些测试打破,但不是很多。

让测试中断是一件好事,代码中的任何更改都应该破坏测试。

答案 8 :(得分:0)

如果需求发生变化,那么您的测试应该是首先要改变的,而不是接口。

我首先要在第一次适当的测试中修改界面设计,更新界面以通过新破解的测试。一旦更新接口以通过测试,您应该看到其他测试中断(因为它们将使用过时的接口)。

应该用新界面设计更新剩余的失败测试,​​以使它们再次通过。

以测试驱动的方式更新界面将确保更改实际上是必要的,并且是可测试的。