testing - 好的测试会导致草率的编码吗？

Question

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

换句话说，您让您（或其他开发人员）编写的很棒的测试来提醒您也更改其他地方的代码。

这是我们可能在自己或其他开发人员身上发现的合法问题吗？

score 4 · Accepted Answer

您在问单元测试是否鼓励您将它们作为 TODO 列表的一种方法？是的，但我不认为这是草率的编码。毕竟，您要从单元测试失败和测试代码开始；如果你重构一些代码，然后再次为测试编写代码，那并不是草率的编码——它正在做你应该做的事情。

我认为单元测试的问题在于你不能在单元测试中涵盖所有极端情况，有时人们认为工作测试意味着工作应用程序，这是不正确的。

score 3 · Accepted Answer

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

您的论点中的谬误集中在“现在就完成”意味着您将通过实施草率的设计来节省时间的前提。事情的真相是，无论您的测试是否良好，您都在招致技术债务。更改该代码现在是一项复杂得多的任务，无论您是否有一个好的测试框架来提醒您这一点。

尽管不成熟的代码可能工作得很好并且完全可以被客户接受，但过多的数量会使程序无法掌握，导致程序员极度专业化，最终导致产品缺乏灵活性。——沃德·坎宁安

良好测试实践的优势可能在于允许您在一定程度上安全地承担债务。只要您继续意识到由于您的选择而导致该代码区域现在很薄弱，那么权衡取舍可能是值得的-您以更高的债务为代价更快地交付产品，并以更低的成本因此，在短期内产生错误的风险。

score 1 · Accepted Answer

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

score 0 · Accepted Answer

我不使用测试作为查找需要更改的代码的首选。我将使用我的 IDE 的搜索（或重构）功能并查找调用相关方法的所有位置。

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

score 0 · Accepted Answer

0

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

于 2009-11-13T19:44:53.187 回答

score 0 · Accepted Answer

无论有没有测试，你都可以写出令人难以置信的草率代码。单元测试使摆脱它变得稍微容易一些，但只是在短期内。

score 0 · Accepted Answer

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

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

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

score 0 · Accepted Answer

在我看来，这听起来更像是马虎的开发人员和马虎的编码实践是导致你的示例中的马虎代码的原因。您描述的测试将防止草率的代码走得太远。

8 回答 8