处理TDD接口变更

Question

处理TDD接口变更

unit-testingtdd

6

我已经开始使用TDD。如先前的问题所述，最大的难点是处理接口更改。在需求变化时，如何减小测试用例的影响？

- Dan Pieczynski

9个回答

7

我认为这是界面被过度使用的流行争论之一的原因之一。

然而，我不同意。

当需求发生变化时，测试也应该随之改变。对吧？我的意思是，如果你编写测试的标准不再有效，那么你应该重写或删除该测试。

我希望这可以帮到你，但我觉得我可能误解了你的问题。

- Ian P

4

会有影响。你必须接受改变界面将需要时间来首先更改相关的测试用例。这是无法避免的。

但是，如果你考虑后面不再试图在此界面中查找难以捉摸的错误并且不在发布周修复该错误所节省的时间，那么改变界面完全值得。

- Ilya Kochetov

1

我们应该怎么做才能防止我们的代码和测试依赖于需求？似乎没有什么办法。每当需求发生变化时，我们就必须改变我们的代码和测试。但也许我们可以简化我们的工作？是的，我们可以。关键原则是：封装可能会改变的代码。

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

- dmitrynikolaev

1

在 TDD 中，你的测试并不是测试，它们是可执行的规格说明。也就是说: 它们是你需求的可执行编码。一定要记住这点。

现在，突然变得清楚了：如果你的需求发生变化，那么测试必须改变！这就是 TDD 的全部意义！

如果你在进行瀑布式开发，你将不得不更改你的规格说明文档。在 TDD 中，你需要做同样的事情，除了你的规格说明不是用 Word 编写的，而是用 xUnit 编写的。

- jwmittag

0

在编写新接口的代码之前，您需要先编写测试。

- Paul Whelan

0

如果您正在遵循测试优先的方法，理论上接口更改不应对您的测试代码产生影响。毕竟，当您需要更改接口时，您首先会更改测试用例以匹配要求，然后再更改接口/实现，直到测试通过。

- Martin Klinke

0

当接口发生变化时，您应该预计测试会出现故障。如果太多的测试出现故障，这意味着您的系统耦合度过高，太多的事情依赖于该接口。您应该预计一些测试会出现故障，但不是很多。

测试出现故障是一件好事，任何代码的更改都应该导致测试出现故障。

- Hibri

0

如果需求发生变化，那么你的测试应该是第一个需要改变的东西，而不是接口。

我会从第一个适当的测试开始修改接口设计，更新接口以通过新的破坏性测试。一旦接口被更新以通过测试，你应该会看到其他测试失败（因为它们将使用过时的接口）。

更新测试驱动方式中的接口将确保更改实际上是必要的，并且可以进行测试。然后，只需更新剩余的失败测试与新的接口设计，使它们再次通过即可。

- Nick

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- spiv · Accepted Answer

更改接口需要更新使用该接口的代码。在这方面，测试代码和非测试代码没有任何区别。不可避免的是，针对该接口的测试需要进行更改。

通常情况下，当接口发生变化时，您会发现“太多”测试失败了，即针对大部分无关功能的测试结果依赖于该接口。这可能表明您的测试过于宽泛，需要进行重构。这种情况有许多可能的方式，但以下示例希望能够展示一般思路以及一个特定案例。

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

这种模式是一种创建方法。

其中的优点在于，您的订单测试方法与账户和地址的创建方式无关；如果这些接口发生更改，则只需更改一个地方，而不是每个使用账户和地址的测试都需要更改。

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