如果更改对其进行单元测试的代码，您首先更改哪些代码？

Question

我正在构建一个项目，我必须将方法更改为略有不同。我已经针对该方法构建了几个单元测试，但是我需要添加更多来完成我要添加的新行为。在进行代码更改之前首先更改/添加这些测试，或者更改代码，修复损坏的测试并添加新测试以覆盖新行为是不错的形式？

Answer 1

如果您要遵循TDD惯例，则应首先更新测试。您将破坏测试用例，这些测试用例在您修复代码时应该会得到修复。

Answer 2

最好先更新测试并让它们失败，然后返回并更新代码，直到测试通过。 A.K.A测试驱动开发或测试第一次开发。

Answer 3

如果您正在进行测试首次开发，至少您必须编写一个新的测试来证明更改的合理性。然后，更改可能会破坏旧测试，如果更改是测试附带的，您可以在看到它们失败后修复它们。但是，如果您知道用于测试旧行为的测试并且只需要针对新行为进行更改，则没有理由不仅仅更改该测试而不是编写新测试。

不值得（在我看来）努力确定哪些测试会随着更改而中断并首先更改它们，因为测试运行器会在您进行更改后告诉您。

编辑（回应评论）：我更喜欢先编写测试，但那是TDD风格。在那种情况下，测试驱动设计。这种发展还有一种节奏和模式（红绿重构）。另一种方式是更纯粹的单元测试方式，你已经设计并实现了你想要的东西，现在你正在测试它。这没有什么不对，它是一种不同的开发方法，选择不依赖于其他测试的存在。这通常是一种开发方法。

Answer 4

我承认我有时会作弊。如果变化很简单，我可以肯定地知道结果，我有时会更改代码，然后进行测试。就像我将一个数乘以一个常数，而我正在做的就是改变常数，我将继续进行更改，然后更新测试用例。

如果你做的事情稍微复杂一些，我建议坚持TDD正统并首先改变测试。在完成之前定义您想要做的事情。此外，我建议在预先存在的测试之后添加新的测试，以便首先运行与您想要保留的现有功能相关的测试，确保您没有破坏任何东西（或提醒您尽早你有。）

Answer 5

我所做的是先编码然后再创建测试。因为你可能有一个案例，你编程你的测试以某种方式工作，然后当你编码，你意识到你不能这样做。因此，您需要再次更改测试。

Answer 6

我个人更喜欢先编写功能然后再进行单元测试（如果适用于特定功能）。如果它不值得单元测试，我通常会跳过它。我发现，将单元测试添加到您编写的all代码中通常是浪费时间。肯定有这样一个地方，它拥有它非常有用，但这几乎不会扩展到你的所有代码。

当您重构某些内容时，很容易发现浪费的生产力，并意识到您已经破坏了一半的单元测试，这些测试并没有真正增加任何价值;因为首先很容易发现故障。所有这些努力都是浪费时间。 如果你在一个没有快速交付和快速适应的动力的环境中工作，那么我想有大量的单元测试是可行的。否则，您只需增加一大笔成本，而无需为用户增加更多价值。