我已经开始使用TDD了。正如an earlier question中提到的,最大的困难是处理界面变化。当需求发生变化时,您如何减少对测试用例的影响?
答案 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)
如果需求发生变化,那么您的测试应该是首先要改变的,而不是接口。
我首先要在第一次适当的测试中修改界面设计,更新界面以通过新破解的测试。一旦更新接口以通过测试,您应该看到其他测试中断(因为它们将使用过时的接口)。
应该用新界面设计更新剩余的失败测试,以使它们再次通过。
以测试驱动的方式更新界面将确保更改实际上是必要的,并且是可测试的。