何时可以更改“已完成”的单元测试？

Question

我已经采取了我的第一个婴儿步骤进入单元测试，并且由于对该域的更好理解，已经对已破坏单元测试的域模型进行了更改。所以这提出了一个问题：

何时允许更改以前的工作单位测试？

我想我不得不提出这个问题而错过了单元测试的一个重要方面......

Answer 1

对于'正确'的TDD，您首先更改测试，然后更改代码。

所以实际上你从不打破了测试，只打破了代码。你应该始终努力使测试成为正确功能的明确表达，因此，先验，正确。

Answer 2

每个特定单元测试的要点并不是它永远不会中断，而是只要它测试的功能也有效，它就会继续工作。这样，对测试功能的意外更改会导致您发现的测试失败，而不是最终用户。

如果故意更改功能，那么您应该会看到一些测试中断。如果不这样做，那么您在测试套件中没有足够的功能覆盖范围。

Answer 3

当您进行破坏测试的更改时：

1）首先要确定测试现在是否已经破坏，或者您的更改是否已经破坏了不应该进行的测试。

2）。如果是前者，请修复测试。否则，请修改您的更改。

Answer 4

当需求发生变化时。无论您是更改代码，然后查看哪些测试因为什么原因（如Mitch建议）而中断，或者更改测试然后更改代码（如Visage所提到的），测试只会在功能假设做不同的事情。

Answer 5

每次需要时。

• 如果测试变得不准确或者不再遵守规范，则应更改测试。
• 如果测试变得无关紧要，则应将其删除。

关键是，您的测试应准确了解您的软件应该如何工作。虽然这将有点难以维护，事实上这是TDD的一个更大的关闭，仅次于测试优先编程。

Answer 6

测试是程序行为的规范。您需要更改规格时更改它们，因为它们是规格。一些我想到的......

• 当代码的要求发生变化且测试与新行为不匹配时，您应该更新它们。
• 当某些要求过时时，应删除指定该行为的测试。

测试代码需要具备的主要品质是可读性。因此，您应该定期更改测试...

• 如果测试难以阅读并且没有透露程序员的每一个意图，那么应该对其进行重构以提高其可读性。

然后还有一些测试被破坏的情况，例如并发代码的脆弱测试，即使代码是正确的，但主要通过但偶尔会失败。在这种情况下，测试应该被修复为更可重复（可能需要更改代码以便更容易测试 - 最好的方法是使用合适的设计模式来避免/限制并发）。