做好的测试可以实现草率编码吗？

Question

假设您正在编码，并且您遇到了简单代码重用的机会（例如，将一段代码拉出到可访问的地方，如Utility类或基类）。您可能会发现自己在想，“我知道这样做很好，但我现在必须完成这项工作，如果我需要更改此代码，请忘记在其他地方，我的测试框架会让我知道。“

换句话说，你让你（或其他开发人员）编写的精彩测试提醒你改变其他地方的代码。

这是我们在自己或其他开发者中可能找到的合法问题吗？

Answer 1

您在询问单元测试是否鼓励您依赖它们作为TODO列表的方法？是的，但我不认为这是邋coding的编码。你毕竟是单元测试失败并开始测试的代码;如果你重构一些代码，然后再次编写测试代码，那就不是编码 - 它正在做你应该做的事情。

我认为单元测试的问题很简单，你无法覆盖单元测试中的每个角落情况，有时候人们会认为工作测试意味着工作的应用程序，这是不正确的。

Answer 2

在您提供的示例中，良好的测试实际上使您能够实现草率设计，但根据我的经验，糟糕的测试不会阻止您做同样的事情。

你的论点中的谬论围绕着“现在完成这件事”的前提，这意味着你将通过实施草率设计来节省时间。问题的真相是，无论您的测试是否良好，您都会承担技术债务。对代码进行更改现在是一项更复杂的任务，无论您是否有一个良好的测试框架来提醒您。

  

虽然不成熟的代码可能正常工作   并完全被接受   客户，多余的数量将使   一个不可交易的程序，导致   程序员的极端专业化   最后是一个不灵活的产品。    - Ward Cunningham

良好测试实践的优势在于允许您以一定程度的安全性承担债务。只要你继续意识到代码的这个区域现在很弱，由于你的选择，那么它可能值得权衡 - 你以更高的债务，更低的成本更快地运送你的产品因此在短期内会产生虫子的风险。

Answer 3

如果测试结果良好且代码（草率或其他）通过它们，那么一切都很好。拥有好的代码会很好，但是工作代码不好比破坏良好的代码好。

Answer 4

我不使用测试作为查找需要更改的代码的第一个选项。我将使用IDE的搜索（或重构）功能，并查找调用该方法的所有地方。

测试只是一个很好的补充，以防我不小心草率或意外引入了一个错误。测试从一开始就不会让我马虎，一旦我认为我已经完成，他们就会安抚我。

Answer 5

我想说好的测试可以让你修复草率的编码。

Answer 6

无论是否有测试，您都可以编写令人难以置信的草率代码。单元测试使得它更容易逃脱，但只是在短期内。

Answer 7

如果您在代码中的两个位置复制了一组逻辑（IMO是开发人员可以做的最糟糕的事情），那么您可能也会进行不一致的测试。

任何程序员都可以做的最重要的工作是无情地重构代码，删除所有重复。这几乎总是在一次迭代中显示出好处。

为什么您认为如果您在2个地方复制的代码出错，那么您的测试会更好？

Answer 8

对我来说听起来更像是草率的开发人员和草率的编码实践是导致你的例子中的草率代码。您描述的测试将阻止草率代码进入远方。