您是如何调整单元测试以应对不断变化的需求的?

根据定义 unit-tests 不要复制应用程序的需求。它们描述了模块的需求。这是一个区别,该模块可以重用,甚至在具有不同需求的应用程序中,或者根本不使用。因此,不断变化的需求不会影响真正的单元测试(除非您必须为新模块编写新的测试,或者为已变化的需求不再需要的模块放弃旧的测试)。

acceptance-tests 处理应用层的需求。所以我想你说的是验收测试。

我将添加新的要求作为新的验收测试。但是对于旧的需求,您必须查看它们,它们是如何被更改的需求失效的。

我将添加新的测试并使其通过。然后,您将看到哪些测试结果被破坏。如果您认为旧测试与新测试相矛盾,则可能必须删除旧测试。否则,您将修改代码以使旧测试也通过。

虽然我同意Mnementh的回答,但对我来说,这是关键的评论。如果测试是需求的翻译版本,那么如果需求已经更改,那么测试必须更改。

正如约翰·梅纳德·凯恩斯(John Maynard Keynes)所说,“当事实发生变化时,我会改变我的观点。你会怎么做,先生?”

我认为这里的情况很糟糕。你的事实已经为你改变了

因为前面的要求是这样的 测试时,似乎将它们更改为 符合新的要求将是必要的

变化发生了。在这种情况下,这意味着更多的工作时间和金钱。如果业务没有问题,你也不应该(除非日程安排不人道:)。如果规格发生了变化,

• 确保已签入工作版本。
• 重复步骤1以确保安全。
• 现在一次进行一个测试。。除非您没有遵循“干/一次且仅一次”原则,否则您需要进行的任何更改都应该放在一个地方。如果没有,您应该更早地进行重构。。但是现在还不算太晚。。在进行更改之前,将代码提取到单个位置
• 重复上一步直到完成

如果您的单元测试不再符合需求,那么它们就不应该存在——毕竟,它们现在告诉您的只是您的代码符合不再存在的需求!

每当您的需求发生变化时,您都应该更改表示变化需求的测试,并验证测试现在是否失败(以前它们都通过了,对吗?;)

我对你的问题有两个答案,一个是哲学上的,另一个是战术上的。

根据我的经验,如果您已经达到了单元测试阻碍更改的程度,那是因为您在测试中有技术债务。

所以我的策略性建议是,在您尝试更改需求之前,您需要重构您的测试。每个测试都应该有一个通过/失败的唯一原因,并且该原因之外的行为应该在共享代码中。这意味着对于任何给定的行为更改,您将有两个地方更改测试:

1. 实际验证该行为的测试
2. 在共享设备代码中使用该行为的位置

您可能会发现本文很有用: Grow Your Harness Naturally . 它实际上是关于用于功能测试的可重用测试工具,但我发现这些想法在我的单元测试中也非常有用。